irrtef 



iNA 960 PROGRAMMER'S 
REFERENCE MANUAL 



Copyright © 1984 Intel Corporation 

Intel Corporation, 3065 Bowers Avenue, Santa Clara, California 95051 Order Number: 122193-001 



iNA 960 PROGRAMMER'S 
REFERENCE MANUAL 



Order Number: 122193-001 



Copyright © 1984 Intel Corporation 
Intel Corporation, 3065 Bowers Avenue, Santa Clara, CA 95051 



Additional copies of this manual or other Intel literature may be obtained from: 

Literature Department 
Intel Corporation 
3065 Bowers Avenue 
Santa Clara, CA 95051 

Intel retains the right to make changes to these specifications at any time, without notice. Contact your 
local sales office to obtain the latest specifications before placing your order. 

Intel Corporation makes no warranty of any kind with regard to this material, including, but not limited 
to, the implied warranties of merchantability and fitness for a particular purpose. Intel Corporation assumes 
no responsibility for any errors that may appear in this document. Intel Corporation makes no commitment 
to update nor to keep current the information contained in this document. 

Intel Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in 
an Intel product. No other circuit patent licenses are implied. 

Intel software products are copyrighted by and shall remain the property of Intel Corporation. Use, dupli- 
cation or disclosure is subject to restrictions stated in Intel's software license, or as defined in ASPR 
7-1 04.9(a)(9). 

No part of this document may be copied or reproduced in any form or by any means without the prior 
written consent of Intel Corporation. 

The following are trademarks of Intel Corporation and its affiliates and may only be used to identify Intel 
products: 



BITBUS 


'm 


iRMX 


Plug-A-Bubblc 


COMMputcr 


iMMX 


iSBC 


PROMPT 


CREDIT 


Insite 


iSBX 


Promwarc 


Data Pipeline 


int c l 


iSDM 


QueX 


Genius 


int e lBOS 


iSXM 


QUEST 


i 


Intelevision 


Library Manager 


Ripplemode 


i 


int e ligent Identifier 


MCS 


RMX/80 


1 2 ICE 


im c ligent Programming 


Megaehassis 


RUPI 


ICE 


Intellec 


MICROMAINFRAME 


Seamless 


iCS 


Intellink 


MULTIBUS 


SOLO 


iDBP 


iOSP 


MULTICHANNEL 


SYSTEM 2000 


iDIS 


iPDS 


MULTIMODULE 


UP! 


iLBX 









SOFTWARE 



REV 



REVISION HISTORY 



DATE 



APPD. 



-001 



Original issue. 



3/84 



R.T. 




PREFACE 



This manual provides all of the details necessary to use iNA 960 Release 1, and is 
intended for use by system designers and application programmers. 

This manual contains nine chapters and five appendixes: 

Chapter 1, "Introduction," presents an overview, describes the ISO model, and 
summarizes the portion of the ISO network implemented by iNA 960. 

Chapter 2, "User Interface to iNA 960," describes the target environments of 
iNA 960 and the user interface to iNA 960. 

Chapter 3, "Data Link Layer," contains the data link services, data link 
commands, and the data link configuration macros. 

Chapter 4, "Network Layer," contains the description of the internet address, 
which must be used when the transport services are used. 

Chapter 5, "Transport Control Layer," describes virtual circuit service, datagram 
service, buffers, and the user interface to the services. 

Chapter 6, "Network Management Facility," describes layer management, down- 
line loading, dumping, echo testing, and the configuration macros (boot server 
and NMF). 

Chapter 7, "ROM-Based NMF," describes the boot consumer facility that can 
be burned into ROM (this facility is used for booting a station from the network). 

Chapter 8, "iRMX 86 System Generation," describes the configuration of the 
communication software for iRMX 86-based systems. 

Chapter 9, "Component Support Interface," describes the message delivery 
mechanisms available, the hardware environment required, and the steps needed 
to configure and initialize the communications software for non-iRMX-based 
systems. 

Appendix A, "iNA 960 Files," describes all the files included on the iNA 960 
delivery diskettes. 

Appendix B, "Network Management Facility Objects," describes all of the objects 
for the network management facility in iNA 960. 

Appendix C, "Sample User Routines for Component Support," describes how 
iNA can be configured to run on an 8086/82586-based system. 

Appendix D, "CONFIGURE Command Parameters," gives the format from the 
CONFIGURE command argument field and describes the command 
parameters. 

Appendix E, "MULTIBUS Interprocessor Protocol (MIP)," is a specification of 
the MIP interface. 
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Notational Conventions 

UPPERCASE Characters shown in uppercase must be entered in the order 

shown. You may enter the characters in uppercase or 
lowercase. 



italic 



Italic indicates a meta symbol that may be replaced with an 
item that fulfills the rules for that symbol. The actual symbol 
may be any of the following: 



directory-name Is that portion of a pathname that acts as a file locator by 

identifying the device and/or directory containing the 
filename. 



filename 
pathname 



Is a valid name for the part of a pathname that names a file. 

Is a valid designation for a file; in its entirety, it consists of a 
directory and a filename. 



pathname - !, Are generic labels placed on sample listings where one or more 

pathname2, ... user-specified pathnames would actually be printed. 



system-id 
Mx.y 



Is a generic label placed on sample listings where an oper- 
ating system-dependent name would actually be printed. 

Is a generic label placed on sample listings where the version 
number of the product that produced the listing would 
actually be printed. 



[ ] 
i > 



Brackets indicate optional arguments or parameters. 

One and only one of the enclosed entries must be selected 
unless the field is also surrounded by brackets, in which case 
it is optional. 
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punctuation Punctuation other than ellipses, braces, and brackets must be 

entered as shown. For example, the punctuation shown in the 
following command must be entered: 

SUBMIT PLM86CPR0GA ,SRC , »9 SEPT 81') 
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CHAPTER 1 
INTRODUCTION 



1.1 JNA960 

iNA 960 is a general purpose local area network software package implementing the 
class 4 services of the ISO transport specification and network management functions. 
iNA 960 is designed to operate in environments consisting of the 8086, 8088, and 
80186 microprocessors and the 82586 communications co-processors. iNA 960 also 
supports Intel's board-level Local Area Network products, the iSBC 550 KIT and 
the iSBC 186/51. Examples for using iNA 960 include network design stations, 
manufacturing process control, communicating word processors, and financial services 
workstations. 



1.2 Functional Overview 

The iNA 960 design is an 8073 standard implementation of the class 4 transport 
protocol defined by the International Standard Organization. The transport layer 
provides a reliable full-duplex message delivery service on top of the IEEE 802.3 
standard packet delivery service implemented by the 82586 (or equivalent) physical 
and data link protocols. 

The software (which consists of linkable modules) can be configured to implement a 
range of capabilities and interfaces. In addition to reliable process-to-process message 
delivery, the capabilities include a datagram service, a boot server, a direct user access 
to the data link layer, and a comprehensive network management facility. The inter- 
face options accommodate the various system environments. 

iNA 960 can be configured to run either under the iRMX 86 operating system along 
with user software, or on top of a dedicated 8086, 8088, or 80186 processor coupled 
with an 82586 to provide a communications front-end processor. 

The software also includes a network management service. This facility enables the 
user to monitor and adjust the network's operation in order to maintain it and opti- 
mize its performance. 

The current release of iNA 960 includes a null network layer supporting the data 
link layer and transport layer interfaces without providing internetwork routing service. 
This capability will be implemented in later releases of iNA 960. 



1.3 The ISO Model Summary 

The following paragraphs summarize the seven layers of the ISO model. Figure 1-1 
illustrates the seven-layer ISO model. 



1.3.1 Application Layer 

The application layer supports public files and file consumers. File consumers are 
stations (nodes) that access files on other stations (nodes). Transparent access for file 
consumers is supported, although a file consumer need not take advantage of it. File 
consumers may or may not have local mass storage devices. If local mass storage is 
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Figure 1-1 . ISO Open Systems Interconnection Model 



not available, the file consumers must rely on other systems for initialization and all 
mass storage capability. 

Public file stations are systems that permit file consumers to access files on their local 
disks and to queue printer requests for their local printers. The application layer only 
supports a limited number of transactions going on simultaneously. For example, a 
workstation with local mass storage could be both a file consumer and a public file 
station. 



This layer is not implemented in iNA 960. 



1.3.2 Presentation Layer 

The presentation layer presents information to communicating application entities in 
a format that preserves meaning while resolving syntax differences. An example of a 
presentation layer function would be the conversion of character codes from EBCIDIC 
to ASCII. 

A presentation entity can access another presentation entity in only two ways: either 
by initiating a session connection or by accepting a session connection. This session 
connection takes place in the session layer. 

This layer is not implemented in iNA 960. 



1.3.3 Session Layer 

The session layer provides the necessary methodology for cooperating presentation 
entities to organize and synchronize the dialogue and to manage the exchange of 
data. This layer also provides for dynamically binding process names to transport 
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addresses. This facility is available for both virtual circuit and datagram transport 
services. The session layer translates process names to transport addresses and uses 
the transport service to provide virtual circuit service between any two processes that 
have names bound to network addresses. The datagram service works in much the 
same manner. Thus, in order to communicate with a remote process, a process need 
only know the name, not the transport address of the remote process. The session 
layer uses the name server of the network management facility to maintain and trans- 
late the process name to transport address bindings. 

A process name is a character string that consists of an individual name or a member 
of a group. Process names are the endpoints of session virtual circuits or datagrams. 
If an endpoint is fully specified, it matches a particular individual or a particular 
member of a group. If an endpoint is partially specified, it matches any member of a 
particular group. 

When a virtual circuit is used, a perfect channel is provided. No errors occur in trans- 
mission, and all packets are delivered in the same order that they were sent. 

When a datagram is used, an attempt is made to deliver each packet as an isolated 
unit. The packets may arrive out of order, or not at all. 

This layer is not implemented in iNA 960. 



1.3.4 Transport Layer 

The transport layer provides transparent transfer of data between session entities. 
Therefore, the transport layer relieves the transport users from any concern with the 
detailed way in which reliable and cost-effective data transfer is achieved. 

The transport layer is designed primarily for user software that has moderate to large 
amounts of data to be transferred over the network. Some examples might be file 
transfers, block data moves, or file sharing applications. 

The transport layer is designed to provide a widely-used, error-free service that does 
not depend on the particular characteristics of any specific lower layer. 



1 .3.5 Network Layer 

The network layer provides the means to establish, maintain, and terminate network 
connections between systems containing communication application entities and the 
functional and procedural means to exchange network service data units between 
transport entities over network connections. 

This layer also provides independence to transport entities from routing and relay 
considerations associated with the establishment and operation of a network connec- 
tion. The network layer of iNA 960 offers a datagram service to higher layer users. 



1 .3.6 Data Link Layer 

The data link layer provides functional and procedural methodology to establish, 
maintain, and release data link connections among network entities. The data link 
layer is responsible for framing, addressing, error detection, and link management. 



1-3 



Introduction iNA 960 



1.3.7 Physical Layer 



The physical layer provides functional and procedural characteristics to activate, 
maintain, and deactivate physical connections for bit transmission between data link 
entities. This layer is directly concerned with the actual transmission medium (wire, 
fiber optics, radio), the signalling means (voltage or current levels), data rate, and 
mechanical specifications. 



1.4 iNA 960 Software 



iNA 960 implements the transport layer, the network layer, and the data link inter- 
face portion of the data link layer from the ISO model, as well as a network manage- 
ment facility. 



1 .4. 1 Transport Layer 



The Transport Layer provides message delivery services between client processes 
running on computers (network hosts or nodes) anywhere in the network. 

Client processes are identified by a combination of a network address defining the 
node and a transport service access point defining the interface point through which 
the client accesses the transport services. The combined parameters, called the trans- 
port address, are supplied by the user for both the local and the remote client processes 
to be connected. The iNA 960 transport layer implements two kinds of message deliv- 
ery services: virtual circuit and datagram. 

The virtual circuit service provides a reliable point-to-point message delivery service 
ensuring maximum data integrity; it is fully compatible with the ISO 8073 class 4 
protocol. The virtual circuit services entail: 

• Reliable Delivery - Data is delivered to the destination in the exact order it was 
sent by the source, with no errors, duplications, or losses, regardless of the quality 
of service available from the underlying network service. 

• Data Rate Matching (flow control) - The transport layer attempts to maximize 
throughput while conserving communication subsystem resources by controlling 
the rate at which messages are sent. That rate is based on the availability of 
receive buffers at the destination and its own resources. 

• Multiple Connection Capability (Process Multiplexing) - Several processes 
simultaneously use the transport layer with no risk that progress or lack of progress 
by one process will interfere with others. 

• Variable Length Messages - The client software can arbitrarily submit short or 
long messages for transmittal without regard for the minimum or maximum 
network service data unit (NSDU) lengths supported by the underlying network 
services. 

• Expedited Delivery - With this service the client can transmit up to 16 bytes of 
urgent data bypassing the normal flow control. The expedited data is guaranteed 
to arrive before any normal data that is submitted afterward. 
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The datagram service provides a best-effort message delivery between client processes 
requiring less overhead, therefore allowing higher throughput than virtual circuits. 
The datagram service entails: 

• The datagram service option transfers data between client processes without 
establishing a virtual circuit. The service is a best-effort capability; data may be 
lost or misordered. Data can be transferred at one time to a single destination or 
to several destinations (multicast). 



1.4.2 Data Link Layer 

The data link option allows the user to access the functionalities of the data link layer 
directly, instead of going through the network and transport layers. This flexibility is 
useful when the user needs custom higher layer software or does not need the network 
layer and transport layer services. 

Through the data link the capabilities supporting the lower layers in iNA 960 are 
made directly available to the user. The data link enables the user to establish and 
delete data link connections, transmit packets to individual and multiple receivers, 
and configure the data link software to meet the requirements of the given network 
environment. 



1.4.3 Network Management Facility 

Network management supplies a network with planning, operation, and maintenance 
facilities. The planning capability gathers network usage information such as peak 
activity, total packets sent, and CRC errors. This information allows the system 
manager to make adjustments for day-to-day usage of the network. Normal day-to- 
day operation deals with network functions such as initialization, termination, 
monitoring, and performance optimization. Maintenance deals with detection, isola- 
tion, amputation, and repair of network faults. Many functions can be performed 
both on local and remote nodes. 

iNA 960 includes extensive network management support for initialization, address 
conversions, operation, and maintenance. Network management is a distributed 
function that is built into every layer. Its activities are being performed constantly to 
ensure the proper operation of the network. Enquiries into the state of the network 
can be made from any system on the network. A central network control station does 
not exist in iNA 960. Network management is the responsibility of every station. 
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2.1 Overview 

The iNA 960 software is designed to run either under iRMX 86 or separately from 
the host on a dedicated front-end processor. Hence, the user has two types of inter- 
faces to iNA 960: the iRMX 86 interface and the component support interface. In 
both environments, the interface is based on exchanging memory segments (called 
request blocks) between iNA 960 and the client. The format and contents of the 
request blocks are virtually the same in both configurations; only the request block 
delivery mechanism is different. 

This chapter describes these two interfaces. The general form of the request block is 
given, along with the procedures for implementing each interface. 



2.2 iRMX™ 86 Interface 

In the iRMX 86 environment, both the user program and iNA 960 run under 
iRMX 86. The communications software is implemented as a first-level user's job 
running on the iRMX 86 nucleus. In addition, if the boot server is configured into 
the communication system, the Basic I/O System (BIOS) is required. Figure 2-1 
shows iNA 960 as an iRMX 86 job. 

iNA 960 will run in any iRMX 86 environment, including configurations based on 
the 80130. Some of the typical hardware implementations include the iSBC 550 KIT 
combined with an 8086-, 8088-, or 80186-based host and the iSBC 186/51 
COMMputer board. 




Figure 2-1 . iNA 960 as an iRMX™ Job 
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With the iRMX 86 interface, the user sends communications commands to iNA 960 
via request blocks. Either the user allocates and constructs the request blocks directly 
(called the request block interface), or available PL/M style procedures construct 
and deliver the request blocks for the user (called the procedure interface). 



2.2.1 iRMX™ 86 User Id 

Before issuing a communications request, the user must acquire a user id. This is 
done by making the following system call: 

C0MM$USER$T0KEN = C Q $ C R E A T E $ C M M $ U S E R (Except ion_ptr ) 

This system call is performed only once for each user job. The returned value is a 
token that identifies the COMM system user. All subsequent communications requests 
should use this value in the User field of the request block or the User parameter of 
the procedure interface, as described in the following sections. 



2.2.2 Request Blocks 

For the request block interface, the iRMX 86 user allocates memory segments called 
request blocks. The components of a request block are called fields. Each request 
block consists of fixed format fields and variable format fields. The fixed format 
fields make up the first 1 6 bytes of the request block, and their field definitions remain 
the same for all request blocks. The definitions of the variable format fields, however, 
depend on the command being issued. 

The general form of a request block is as follows: 

DECLARE Rb STRUCTURE ( 

Reserved ( 2 ) WD RD , 

Length BYTE , 

User WORD , 

R e s p o n s e_p o r t BYTE, 

Retur n_ma ilbox WORD, 

Segment^token WORD, 

Subsystem BYTE, 

Opcode BYTE, 

Response WORD, 

Arguments (t)BYTE); 

where 

Reserved is reserved for a system pointer. 

Length is the length (in bytes) of the request block. 

User is an identifier specifying the iRMX 86 user issuing the 

command. This identifier is obtained by making a call to the 
function CQ$CREATE$COMM$USER, as described in the 
previous section. 

Response_port is OFFH for the iRMX 86 user. 

Return_mailbox is a token for the iRMX 86 mailbox where the request block 
is returned. 

Segment_token is an iRMX 86 token for the request block segment. 
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Subsystem has the following interpretation: 

20H-Data Link Layer 

40H-Transport Layer Virtual Circuit Services 
41H-Transport Layer Datagram Services 
80H-Network Management Facility 

Opcode is a code identifying the specific command to be performed. 

See each command for the appropriate value. 

Response is set by iNA 960 after performing (or attempting to perform) 

the command. This indicates the result of executing the 
command. 

Arguments are specific to each command. 



2.2.3 Request Block Interface 

To issue a particular command, the user fills in the fixed format argument fields as 
required by the command. The user then calls the following iRMX 86 extension 
procedure: 

CALL CQ$CDMM$RB (Rb_token, Excep t ion_pt r) 



where 

Rb_token 
Exception_ptr 



is an iRMX 86 token for the request block segment. 

is a pointer to a word field that is to contain the returned 
exception code. For descriptions of iRMX 86 exception codes, 
see the Intel publication Getting Started with the Release 5 
iRMX 86 System. 



This procedure delivers the request block to iNA 960 for processing. At some future 
time, iNA 960 returns the request block to the mailbox specified in the 
Return_mailbox field of the request block. The iRMX 86 user then retrieves the 
request block from the mailbox to determine the result of the request and obtain any 
data received as a result of the request. 

After processing a command, iNA 960 returns a response code in the Response field 
of the request block. This code indicates whether the command was executed success- 
fully; if the command was not executed successfully, the code specifies the reason the 
command was terminated abnormally. 

After extracting the returned request block from the return mailbox, the iRMX 86 
user can determine from the Subsystem and Opcode fields which command was 
returned. By examining the Response field, the user can take appropriate action for 
that command. 



2.2.4 Procedure Interface 

The procedure interface provides the iRMX 86 user with a friendlier processing 
environment than the request block interface. Here, the allocation and formatting of 
the request blocks are performed by the iNA 960 software. The user simply calls the 
procedure form of the command with parameters that specify the user's command 
options. See each command description for the format of the procedure call and for 
descriptions of the command parameters. 
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As an example, the ECHO command of the network management facility has the 
following procedure call format: 

CALL CQ$NMF$ECHO (Transmi t_data_count , D a t a 1 i n k_a d d r_p t r , 
User, R e t u r n_m a i 1 b o x , Except i on_p t r ) 

The response interface is non-procedural. That is, the end of command processing is 
the same as for the request block interface: the request block created from the proce- 
dure call is returned to the mailbox specified by the Return_mailbox parameter. The 
user must inspect the Subsystem, Opcode, and Response fields of the returned request 
block to determine the appropriate course of action, then delete the request block 
segment. 

Each procedure also returns an exception code that usually indicates the status of 
parsing the parameter list for syntax. 

Although the procedure interface is easier to use, it is more expensive than the request 
block interface in terms of processing overhead. The user must decide if the conven- 
ience of using the procedure interface is worth the reduction in performance. 



2.2.5 User Include Files and Libraries 

The iNA 960 delivery diskettes contain include files and user interface libraries. 
These are described in Appendix A. 

The user must include some of the include files in the PL/M 86 procedures, as deter- 
mined by the system calls used in the program. The include files are as follows: 

CQRB.EXT - Request block interface. 

CQTL.EXT - Transport procedure interface. 

CQNMF.EXT - NMF procedure interface. 

CQDL.EXT - Data link procedure interface. 

During the link process the appropriate iNA 960 user interface library must be linked. 
There are two libraries, one for COMPACT, and one for LARGE and MEDIUM 
modes. These contain the routines that satisfy external references to system calls made 
in the application code. The libraries are as follows: 

CQC.LIB - COMPACT mode. 

CQL.LIB - LARGE or MEDIUM mode. 



2.3 Component Support Interface 

The iNA 960 software can be configured to support implementations where 
iRMX 86 is not the primary operating system, where communications tasks are 
separated from the host to increase performance, or where an existing front-end 
communications processor configuration is being upgraded. iNA 960 supports such 
implementations by providing network services on an 8086, 8088, or 80186 processor. 
In these hardware environments, the component support interface is used for submit- 
ting commands to iNA 960. This interface uses a request block interface similar to 
the iRMX 86 interface. The procedure call interface, however, is not available to the 
component support user. 

See Chapter 9 for details on the component support interface. 
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3.1 Overview 

The data link layer is responsible for transmitting data over the network. The data 
link layer performs framing, addressing, and collision handling. The iNA 960 data 
link is a datagram service only, and does not ensure accurate reception of data. Relia- 
ble communication over the network is provided by the transport layer virtual circuit 
service. 

In addition to transmitting packets of data, the data link layer receives incoming 
packets, checks them for CRC errors, and routes them to the proper user process. 
The data link layer also keeps statistics that monitor the performance of the node 
and the rate of errors. These objects are available to the network management layer 
to read and set. Finally, the data link layer is responsible for configuring the 82586 
controller. 

Figure 3-1 shows the partitioning of the data link and physical layers into functions 
performed by the 82501, 82586, and iNA 960 data link software. Data link software 
is responsible for controlling the 82586 and interfacing with the other software 
modules. 

The iNA 960 data link and physical layers conform to the IEEE 802 specifications. 
This is also illustrated in Figure 3-1. Data link software implements class I of the 
Logical Link Control (LLC) sublayer as described in the IEEE 802.2 standard. The 
82586 and 82501 together implement the Media Access Control sublayer as described 
in the IEEE 802.3 standard. The media access method used is Carrier-Sense Multi- 
ple-Access with Collision Detection (CSMA/CD). 



DATA LINK 
LAYER 






LLC 
(IEEE 802.2) 




MAC 
(IEEE 802.3) 


PHYSICAL 
LAYER 






ISO MODEL 


IEEE SPECIFICATION 



Figure 3-1 . Comparison of ISO Model /IEEE Specification 122193-3 
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The user accesses the services of the data link through the iRMX 86 request block, 
iRMX 86 procedure call, or component support interface. Data link commands avail- 
able include Transmit, Post buffers, Data link host address setup, and Configure (the 
hardware controller). Data link parameters can be read and cleared using the network 
management facility. 

The data link layer is initialized by a configuration module as described in 
Section 3.5. 



3.2 Hardware Environment 

Future releases of iNA 960 may support different data link protocols. Currently, 
however, only a single data link controller class is supported: the 82586. Within this 
class of controllers, there are four subclasses. This differentiation is necessary because 
of variations at the board level implementations or simulations of the 82586 interface. 

Following are the four subclasses of the 82586 controller class: 

iSBC 550FW A board level simulation of the 82586. It requires slightly 

different interfaces from those of the 82586. 

iSBC 552 Uses memory-mapped signaling and some predefined address 

locations. 

iSBC 186/51 The single board COMMputer. The software resets the 

loopback mode on the board when data link is initialized. 

general_82586 The same as the 186/51, except the loopback mode is not 

reset. 



3.3 Data Link Communication Protocol 

As shown in Figure 3-1, the data link layer and the physical layer together corre- 
spond to the LLC class I sublayer of the IEEE 802.2 specification and the MAC 
sublayer of the IEEE 802.3 specification. This specification features a CSMA/CD 
media access protocol and packet framing as described in this section. Data link users 
are identified by link service access points (LSAPs), also described in this section. 



3.3.1 Link Service Access Points (LSAPs) 

Data link users communicate via link service access points (LSAPs). An LSAP is a 
code that identifies a specific user process or another layer (see Figure 3-2). These 
codes are explicitly defined as follows: 

Data Link Layer 00H 

Transport Layer FEH 

Network Management Layer 08H 

User Process multiple of 4 in the range 12 < LSAP < 255 

Each receiving process is identified by a destination LSAP (DLSAP), and each 
sending process is identified by a source LSAP (SLSAP). 
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Figure 3-2 . Data Link Interface 



When a packet is sent, the destination process is identified by the DLSAP field in 
the first data buffer. Before a destination process can receive a packet, however, its 
DLSAP must be included in a list of the active LSAPs for the destination data link. 
The data link layer only receives packets targeted for LSAPs on its active list. 

To add an LSAP to the active list, use the CONNECT command. When a connection 
is no longer needed, it should be disconnected. This is done with the DISCONNECT 
command. A maximum of eight LSAPs can be active at one time. 



3.3.2 Logical Link Control Sublayer (IEEE 802.2 class I) 

The iNA 960 software incorporates a class I Logical Link Control (LLC) sublayer 
within the data link layer, as described in the IEEE 802.2 specification. This is a 
datagram service only; it does not ensure the reliable reception of data. 



3.3.3 Media Access Sublayer (IEEE 802.3) 

In addition to the LLC sublayer, the data link layer also contains a Media Access 
sublayer (MAC) that is based on the IEEE 802.3 specification. The MAC uses a 
medium access technology known as Carrier-Sense Multiple-Access with Collision 
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Detection (CSMA/CD). In addition, the medium used has a bus topology as stated 
in the IEEE 802.3 specification. The MAC sublayer of the data link layer performs 
the following functions: 

• Framing - frame boundary delimitation and frame synchronization. 

• Addressing - handling of source and destination addresses. 

• Error detection - detection of physical medium transmission errors. 

• Medium allocation - collision avoidance. 

• Contention resolution - collision handling. 

Before transmitting a packet, the MAC tests the carrier-sense signal. If the signal 
indicates that the bus is not busy, the packet is transmitted. If, however, the bus is 
busy, the MAC waits for the carrier-sense signal to change. After the channel has 
been freed, the MAC delays transmission for an additional period of time called the 
interframe gap period, then attempts to transmit the packet again. 

One station can access the bus. Before the carrier-sense signal can propagate to all 
the other stations, a second station may also access the bus. This results in two inter- 
fering transmissions, in other words, a collision. 

When the physical layer detects a collision, it raises the collision detect signal. The 
MAC then transmits a bit pattern called a. jam. This ensures that the duration of the 
collision is long enough to be detected by all the stations involved in the collision. 
After the jam, each station terminates transmission and waits a random period of 
time before attempting a retransmission. 

As many retransmissions as needed are attempted to successfully transmit the packet 
(up to a configurable limit). However, since repeated collisions are an indication of a 
busy medium, the MAC attempts to reduce this load by successively increasing the 
time interval from which the retry delay period is randomly selected. 



3.4 Data Link Commands 

This section gives a brief introduction to the data link commands, followed by a 
detailed description of each command. 

Data link identifies users by LSAPs. Therefore, a user must establish an LSAP with 
data link. Any incoming packet with this LSAP is routed to this user. The connection 
between a user and an LSAP is established and severed using the following commands: 

CONNECT Establishes a connection between a user process and an LSAP. 

DISCONNECT Severs the connection between the user process and the LSAP. 

Data is transmitted over the network with the following command: 

TRANSMIT Transmits a given packet over the network. 

A packet descriptor is an iNA 960 request block with argument fields that contain 
locations of buffers attached to the request block. A buffer is any user memory 
segment set aside to hold data. To receive incoming data destined for a particular 
user (LSAP), packet descriptors and sufficient buffers must be posted. This is done 
with the following two commands: 

POST_RPD Posts a receive packet descriptor that optionally specifies a 

set of buffers to hold incoming packets. 



3-4 



iNA 960 Data Link Layer 



POST_RBD Posts a single buffer for holding incoming data (in addition 

to any buffers posted by the POST_RPD command). 

Finally, certain data link parameters may be set dynamically by the application. These 
parameters include the host id (except for the iSBC 550 FW) and the multicast 
address list. In addition, the 82586 class hardware controller can be configured in a 
limited way (see Appendix D). Commands that change these parameters are the 
following: 

CONFIGURE Sends configuration information to the data link controller. 

IA_SETUP Sets the host id of the local node. 

MC_ADD Adds a multicast address to the list of active multicast 

addresses for the node. 

MC_REMOVE Removes a multicast address from the list of active multicast 

addresses for the node. 
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3.4.1 CONNECT 

This command provides a connection between the COMM system user (specified by 
the User parameter) and the given DLSAP. If the DLSAP is already active, a new 
association replaces the old one. Only eight DLSAPs can be active, and each user 
can have only one connection. 

NOTE 

A connection to a given LSAP must be made before any buffers or packet 
descriptors can be posted to that LSAP. An attempt to connect more than 
eight DLSAPs results in a Connect command error (exception code 10H). 
Also, each data link COMM system user (each iRMX 86 job using COMM) 
can have only one LSAP. 

Request Block Format 

DECLARE Connect_rb STRUCTURE ( 

Rb_header (6) WORD , 

Subsystem BYTE, 

Opcode BYTE, 

Response WORD, 

Dl sap BYTE , 

Reserved BYTE, 

Port BYTE ) ; 

Procedure Call Format 

CALL CQ$DL$CONNECT (Subsystem, Dlsap, User, 
Return_mailbox, Except ion_p t r ) ; 

Command Parameters 

Opcode 82H. 

Dlsap The DLSAP for the connection. This must be a multiple of 4 

and have a value between 12 and 255. 

Port Must be set to OFFH. 

Subsystem 20H. 
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3.4.2 DISCONNECT 

If the specified connection exists, it is severed. If the connection does not exist, the 
command is ignored. When a connection is disconnected, all receive buffers and packet 
descriptors posted with this LSAP (and this LSAP's associated unique COMM user 
id) are returned to the user. Since a packet descriptor can hold up to four buffers, 
the user must ensure that the number of buffers posted does not exceed four times 
the number of packet descriptors. 

Request Block Format 

DECLARE Di s connec t_r b STRUCTURE ( 

Rb_header (6) WORD , 

Subsystem BYTE, 

Opcode BYTE, 

Response WORD, 

Dl sap BYTE , 

Reserved BYTE ); 

Procedure Call Format 

CALL CQ$DL$D I SCONNECT (Subsystem, Dlsap, User, 
Return_mailbox, Except ion_pt r ) ; 

Command Parameters 

Opcode 83 H. 

Dlsap The DLSAP for the connection. This must be a multiple of 4 

and have a value between 12 and 255. 

Subsystem 20H. 
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3.4.3 TRANSMIT 

This command transmits a packet consisting of from one to four buffers. If the total 
number of bytes transmitted is less than the minimum packet size, padding is done 
by data link. This padding is transparent to the user. 



Request Block Format 

DECLARE Transmit_rb STRUCTURE ( 

(6) WORD , 
BYTE , 
BYTE , 
WORD , 
WORD , 
WORD , 
(4) WORD , 
( 4 ) POINTER 
POINTER ) ; 



R b_h eader 

Subsystem 

Opcode 

Response 

Reserved 

B u f _c o u n t 

B y t e_c o u n t 

fiu f_l c 

D s t_a d d r_p t r 



Procedure Call Format 

CALL CQIDL.ITRANSMIT (Subsystem, B u f _p a r a m_t o k e n , 

Dst_addr_ptr, User, Return_mailbox, Exception_ptr); 

Command Parameters 



Opcode 
Buf_count 

Byte_count 

Bufjoc 

Dst_addr_ptr 

Subsystem 
Buf_param_token 



84H. 

The number of buffers specified by the command. The number 
of buffers can range from to 4. 

An array of 4 words. Each Byte_count (i) is the size in bytes 
of buffer i. 

An array of 4 pointers. Each Buf_loc (i) is a pointer to the 
start of buffer i. 

A pointer to an array of 6 bytes where the destination Host_id 
is stored. 

20H, 

The token for a segment that has the following form: 

DECLARE Buf_param STRUCTURE ( 
Bu f_c oun t WORD , 
By t e_c ount (4) WORD, 
Buf_token (4) TOKEN ) ; 

Here, Buf_count and Byte_count are as described above. 
Buf_token (i) is a token to buffer memory segment i. 



User Data Buffers 

The first buffer specified by the TRANSMIT command contains ISO control infor- 
mation in addition to user data. The second and all subsequent buffers contain only 
user data. The first buffer takes the following form: 



DECLARE Firs t_t r an sm i t. 
Destinatio n_l sap 
Sourc e_l sap 
I s o_c m d 
Data 



.buffer STRUCTURE 
BYTE , 
BYTE , 
BYTE , 
( * ) BYTE ) ; 



( 
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The fields of the user transmit buffers have the following interpretation: 



Destination_lsap 

Source_lsap 

Iso_cmd 

Data 



The LSAP for the destination entity to which the packet is 
forwarded. 

The LSAP for the source entity that sends the packet. 

Must be set to 03H for user data, as specified by IEEE 802.2. 

An array of BYTES that contains the actual data to be trans- 



mitted. 

All of the remaining buffers have this format: 

DECLARE Nex t_t ransmi t_buf f er STRUCTURE ( 
Data CO BYTE ) ; 

Note that for the first transmit buffer, the value of the Byte_count parameter includes 
Destination_lsap, Source_lsap, and Iso_cmd. 
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3.4.4 POST_RPD 

The POST_RPD command posts a single packet descriptor together with up to four 
user buffers. This user packet descriptor and any associated buffers are kept by data 
link until they are used to hold information on a receive packet. An LSAP must be 
established with the CONNECT command before receive packet descriptors and 
buffers can be posted to that LSAP. 

When a packet is received by data link, it is associated with a user packet descriptor 
and buffers posted at the receiving destination LSAP. The packet descriptor provides 
information on the return mailbox where the user waits for receive data. 



Request Block Format 

DECLARE Post_rpd_rb 
R b_h eader 
Subsystem 
Opcode 
Response 
D 1 sap 
Reserved 
B u f _c ount 

Retur n c ount 

B y t e_c ount 
Bu f_l o c 



STRUCTURE ( 
(G) WORD , 
BYTE , 
BYTE , 
WORD , 
BYTE , 
BYTE , 
WORD , 
WORD, 
(4) WORD , 
( 4 ) POINTER 



Procedure Call Format 



CALL CQ$DL $ P0ST$ RPD (Subsystem, Dlsap, Buf_param. 
User, Retur n_m ailbox, Exceptio n_p t r) ; 



token 



Command Parameters 



Opcode 
Dlsap 

Buf_count 



Return_count 
Byte_count 
Bufjoc 
Buf_param_token 



85H. 

The DLSAP for the connection. This must be a multiple of 4 
and have a value between 12 and 255. 

The number of buffers associated with the packet descriptor. 
The number of buffers can range from to 4. When the 
request block is given to data link, this field contains the 
number of buffers posted with this request block. When the 
request block is returned to the user, this field contains the 
number of buffers returned with the packet descriptor. 

Filled in by data link. This is the total number of bytes in the 
receive packet returned by data link. 

An array of 4 words. Each Byte_count (i) is the size in bytes 
of buffer i. 

An array of 4 pointers. Each Bufjoc (i) is a pointer to the 
start of buffer i. 

The token for a segment that has the following form: 

DECLARE Buf_param STRUCTURE ( 

Bu f_c ount WORD , 

By t e_c ount (4) WORD, 

Buf_token (4) TOKEN ) ; 

Here, Buf_count and Byte_count are as described above. 
Buf_token (i) is a token to buffer memory segment i. 
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User Data Buffers 

The first buffer returned with a packet descriptor contains destination and source 
addresses, ISO control information, and user data. The second and all subsequent 
buffers contain only user data. The first receive buffer must be at least 1 7 bytes long; 
it has the following form: 



DECLARE F i rs t_recei ve_buf f er STRUCTURE ( 



Destinatio n_a d d r 
S o u r c e_a d d r 
Informatio n_l e n 
Destinatio n_l sap 
Sourc e_l sap 
I s o_c m d 
Data 



BYTE 
BYTE 



(16) 
(16) 

WORD, 
BYTE , 
BYTE , 
BYTE , 
( # ) BYTE ) 



The remaining buffers have this format: 

DECLARE Nex't_r ece i ve_buf f er STRUCTURE ( 
Data ( * ) BYTE ) ; 

The fields of the user receive buffers have the following interpretation: 



Destination_addr 
Source_addr 
Information len 



Destination_lsap 

Source_lsap 

Iso_cmd 

Data 



The host id of the destination node. 

The host id of the source node. 

Identical to the Return_count field of the request block. Both 
parameters contain the number of information bytes in a 
received packet. This value is the number of bytes received 
subsequent to an Informationjen field. 

The LSAP for the destination entity to which the packet is 
forwarded. 

The LSAP for the source entity that sends the packet. 

Set to 03 H for user data, as specified by IEEE 802.2. 

An array of bytes that contains the actual data. 



For the first receive buffer, the Byte_count parameter includes the first 17 bytes of 
control information. 

Note that the last returned buffer may contain less information bytes than the full 
buffer size. To determine the number of data bytes in the last buffer, subtract all the 
previous buffer sizes (these buffers will be full) from Return_count. 
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3.4.5 POST_RBD 

This command posts a single receive buffer described by the parameters Buf_count 
and Buf_token. An LS AP must be established with the CONNECT command before 
any receive buffers can be posted at this LSAP. 

After the command to post a buffer is given, the request block is immediately returned 
to the user. Note that this is in contrast to the POST_RPD command. Data link 
keeps the buffer posted and associates it with a packet descriptor when this buffer is 
used and returned to the user. 



Request Block Format 



DECLARE Post_rbd_rb STRUCTURE ( 



R b__h eader 
Subsystem 
Opcode 
Response 
D 1 5 a p 
Reserved 
B y t e_c o u n t 
Bu f_l o c 



(6) WORD 
BYTE , 
BYTE , 
WORD, 
BYTE , 
BYTE , 
WORD , 
POINTER 



Procedure Call Format 

CALL CQ$DL$POST$RBD (Subsystem, Dlsap, Buf_token, 

Byte_count, User, Retur n_m ailbox, Exception_ptr); 

Command Parameters 



Opcode 
Dlsap 

Byte_count 
Bufjoc 
Buf token 



86H. 

The DLSAP for the connection. This must be a multiple of 4 
and have a value between 12 and 255. 

The size (in bytes) of the buffer. 

A pointer to the start of the buffer. 

A token for the receive data buffer segment. 



User Data Buffers 

See the POST_RPD command for a description of the format of the user data buffers. 
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3.4.6 CONFIGURE 

This command configures the data link controller. The configuration information is 
contained in a segment of memory that may be up to 12 bytes long. With the request 
block format, the actual configuration data is part of the request block. For the 
procedure format, a pointer to the configuration data is passed as a parameter to the 
procedure. 

For the 82586 class controller, the following restrictions apply to the configuration 
data: 

• The address allocation bit is always reset. 

• The save bad packet option is always OFF. 

• The host id must be 6 bytes long. 

• Data link performs packet padding operations. The user must not alter the 
minimum packet length parameter. 

See Appendix D for a description of the configuration segment. 

Request Block Format 

DECLARE Configure_rb STRUCTURE ( 

Rb_header (6) WORD, 

Subsystem BYTE, 

Opcode BYTE, 

Response WORD, 

Reserved WORD, 

Count WORD, 

Configure (12) BYTE ); 

Procedure Call Format 

CALL CQ $DL $ C ONF I GURE (Subsystem, Count, C o n f i g_i n f o_p t r , 
User, Retur n_m ailbox, Exceptio n_p t r ) ; 

Command Parameters 

Opcode 88H. 

Count The size in bytes of the configuration information. This can 

be up to 12 bytes. 

Configure An array of 12 bytes that is the actual configuration infor- 

mation segment. 

Config_info_ptr A pointer to the configuration information segment. 
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3.4.7 IA_SETUP 

This command sets up the individual address (host id) for a node. For the iSBC 550 
the command becomes an address read command because the host id on an iSBC 550 
FW cannot be changed by the software. 

Request Block Format 

DECLARE Ia_setup_rb STRUCTURE ( 

Rb_header (6) WORD , 

Subsystem BYTE, 

Opcode BYTE, 

Response WORD, 

Reserved WORD, 

Count WORD, 

Address (6) BYTE ) ; 

Procedure Call Format 

CALL CQ$DL$ I A$SETUP (Subsystem, Count, Ia_addr_ptr, 
User, Retur n_m ailbox, Exceptio n_p t r ) ; 

Command Parameters 

Opcode 89H. 

Count The size in bytes of the host id. This number must be 6. 

Address An array of 6 bytes that comprise the host id. 

Ia_addr_ptr A pointer to the start of a memory segment that contains the 

host id. 
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3.4.8 MC_ADD 

This command adds a multicast address to the data link multicast address list. Multi- 
cast addresses can only be added one at a time. Note that the iNA 960 data link 
performs perfect multicast filtering, whereas the 82586 controller performs imperfect 
multicast filtering. 

With the request block format, the actual address is part of the request block. With 
the procedure format, the address is stored as a segment of memory. A pointer to the 
segment is then passed as a parameter to the procedure. 

Request Block Format 

DECLARE Mc_add_rb STRUCTURE ( 

Rb_header (6) WORD, 

Subsystem BYTE, 

Opcode BYTE, 

Response WORD, 

Reserved WORD, 

Count WORD, 

Mc_addr es s (6) BYTE ) ; 

Procedure Call Format 

CALL CQ$DL$ADD$MC (Subsystem, Count, Mc_addr_ptr, 
User, Retur n_m ailbox, Exceptio n._p t r ) ; 

Command Parameters 

Opcode 87H. 

Count The size in bytes of a multicast address. This number must 

be 6. 

Mc_address An array of 6 bytes that comprise the multicast address. 

Mc_addr_ptr A pointer to the start of a memory segment that contains the 

multicast address. 
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3.4.9 MC_REMOVE 

This command removes a single multicast address from the list of active multicast 
addresses for a given data link. With the request block format, the address is part of 
the request block. For the procedure format, the address is stored in memory, and a 
pointer to the memory location of the address is passed as a parameter to the 
procedure. 

Request Block Format 

DECLARE Mc_remove_rb STRUCTURE ( 

Rb_header (6) WORD, 

Subsystem BYTE, 

Opcode BYTE , 

Response WORD, 

Reserved WORD, 

Count WORD, 

Mc_addr ess (6) BYTE ) ; 

Procedure Call Format 

CALL CQ$DL$REMOVE$MC (Subsystem, Count, Mc_addr_ptr, 
User, Return__mailbox, Except ion_p t r ) ; 

Command Parameters 

Opcode 8AH. 

Count The size in bytes of a multicast address. This number must 

be 6. 

Mc_address An array of 6 bytes that comprise the multicast address. 

Mc_addr_ptr A pointer to the start of a memory segment that contains the 

multicast address. 
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3.5 Configuration 

The procedure used to configure and initialize the COMM system is described in 
Chapters 8 and 9. This procedure includes setting up the configuration file for each 
layer. These files consist of calls to configuration macros to set the operating param- 
eters of the layers. This section defines the configuration macros for the data link 
layer. 



3.5.1 Data Link Configuration Macros 

The data link configuration macros define the data stucture of the data link layer. 
Calls to these macros are included in the configuration file DLCFG.A86. This file 
should be updated to reflect the desired data link configuration, and the result assem- 
bled to generate the configuration module DLCFG.OBJ. This module is then included 
in the link list when linking the communication system. 

The file DLCFG.MAC contains the data link configuration macros. Therefore, the 
configuration file must contain the following include statement before any macro 
calls: 

$ I N C L UDE (:SD:COMM/CONFIG/DLCFG.MAC) 

Following are the data link configuration macros; they are given in the order that 
they should appear in the configuration program: 

DL_CTRL Specifies the controller subclass of the hardware. 

DL_INT Specifies the interrupt level used by the data link layer. 

DL_SIGN Specifies how the iNA processor signals the data link 

controller. 

DL_SCP_ADDRESS Specifies the location of the system control pointer (SCP). 

DL_ISCP_ADDRESS Specifies the location of the intermediate system control 
pointer (ISCP). 

DL_HOSTID Specifies where the default host id can be read. 

DL_CONFIG Specifies the default configuration of the 82586 controller and 

some channel characteristics. 

DL_INTERNAL Used internally to generate the IEEE 802 protocol for the 

82586 class of controllers. 



3.5.2 DL_CTRL 

This macro informs the data link software whether the target system is an iSBC 
550FW, iSBC 186/51, iSBC 552, or general_82586. This macro takes the following 
form: 

X DL_CTRL (Ct 1 r_5ubc lass) 

where 

Ctrl_subclass is the controller subclass and has the following values: 

00H - 550FW 
01H- 186/51 
02H - 552 
03H - general_82586 
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The general_82586 controller subclass is created to allow for an iSBC 186/51 -like 
environment. The basic assumption is that the environment must provide I/O ports 
where a default host id can be read during initialization. If these ports are not avail- 
able, the user can provide one or more "dummy" host id ports that can be read during 
initialization. Subsequently, an Ia_setup command can be used to establish the desired 
host id. 

Aside from the fact that the iSBC 186/51 provides six port addresses where the default 
host id can be read, the difference between subclasses 1 and 3 is that for subclass 1 
data link resets the loopback mode on the iSBC 186/51 during initialization. No 
action is taken for a general_82586 subclass controller. For a general_82586 control- 
ler, the user must assume the responsibility for initializing the environment where 
data link functions. 



3.5.3 DLJNT 

This macro specifies the interrupt level used by data link and has the following form: 
X DL_I NT (I n t_l eve 1 ) 



where 



Int_level is the interrupt level. This parameter has the same format as 

that defined by the iRMX 86 nucleus and has these bit 
assignments: 

bits 7-15 must be set to 0. 

bits 4-6 first digit (0-7) of the interrupt level. 

bit 3 set to if a slave level is specified. Here, bits 

0-2 specify the second digit of the interrupt 
level. 

set to 1 if a master level is specified. Here, 
bits 4-6 represent the entire level. 

bits 0-2 second digit (0-7) of the interrupt level 

(defined only if bit 3 is 0). 



3.5.4 DL_SIGN 

The macro DL_SIGN is used to specify how the iNA processor signals the data link 
controller. In addition, the macro specifies the I/O port or memory location used by 
the processor to signal the controller (if signaling is used.) The macro has the follow- 
ing form: 

X DL_SIGN ( S i g na l_t y p e , Signal_info) 



where 



Signal_type specifies how the processor signals the data link controller. 

The values are as follows: 

00H - processor never signals the controller. SignaMnfo is 
not defined. 

01 H - memory-mapped signaling. The processor signals the 
controller with a write to the memory location speci- 
fied by Signal_info. 
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02H - I/O-mapped signaling. The processor signals the 
controller with a write to the I/O port location speci- 
fied by SignaLjnfo. 

SignaMnfo depends on the value of Signal_type, as follows: 

If SignaLtype is 0, this parameter is not defined. 

If SignaLtype is 1, this parameter must contain the upper 16 
bits of the 20-bit memory location to which the processor 
writes. In particular, memory-mapped signaling locations are 
at 16-byte boundaries. 

If SignaLtype is 2, this parameter must contain the 16-bit 
number of the I/O port used by the processor to signal the 
controller. 

The SignaLtype should be set according to the controller subclass. The following 
values are used: 

iSBC 1 86/5 1 - 02H (I/O-mapped) 

iSBC 550 FW - 02H (I/O-mapped) 

iSBC 552 - 01 H (memory-mapped) 

general_82586 - 01 H (memory-mapped) or 02H (I/O-mapped) 

Signal_info should be set as follows: 

iSBC 1 86/51 - 00C8H (the port that channels to the 82586) 

iSBC 550 FW - One of the I/O ports defined in the iSBC 550FW Hardware 

Reference Manual 

iSBC 552 - 4200H (a reserved number) 

general_82586 - Any value compatible with the hardware 



3.5.5 DL_SCP_ADDRESS 

The macro DL_SCP_ADDRESS is used to specify the address of the system control 
pointer (SCP) of the data link controller. This macro has the following form: 

X DL_S C P_ADDR E S S ( S c p_a d d r_o f f 5 e t , S c p_a d d r_b a 5 e ) 

where 

Scp_addr_offset is the offset of the SCP address. 
Scp_addr_base is the base of the SCP address. 

For the iSBC 186/51, iSBC 552, and general_82586 controller subclasses, the address 
of the SCP should be set to FFFF:6H. The iSBC 550 FW allows several SCP locations. 
See the iSBC 550 FW Hardware Reference Manual for details. 



3.5.6 DL_ISCP_ADDRESS 

This macro is used to specify the intermediate system control pointer (ISCP) and has 
the following form: 

X DL_I SCP_ADDRESS ( I s c p_a d d r_o f f 5 e t , I s c p_a d d r_b a 5 e ) 
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where 

Iscp_addr_offset is the offset of the ISCP address. 
Iscp_addr_base is the base of the ISCP address. 

The ISCP offset must be set to to be compatible with the 82586 controller. Other 
than this requiremenet, the ISCP location is completely configurable. However, if 
the user desires to conform to the iRMX 86 operating system, the ISCP should be 
located at 00FF:0H. 

3.5.7 DL_HOSTID 

The macro DL_HOSTID is used to specify the port numbers where the default 
host id can be read. The format of the macro is as follows: 

X DL_H Q ST I D ( H o s t i d_c n t , Hostid_locO, Host id_loc 1 , 

Ho5tid_loc2, Host id_loc3 , H o 5 t i d__l o c 4 , Hostid_loc5) 

where 

Hostid_cnt specifies the number of host id address bytes. This number 

must be 6. 

Hostid_loc0-5 are the I/O port numbers of the ports where the host id 
address bytes can be read. 

The host id read from the port locations specified by this macro constitutes the default 
host id upon initialization. The host id may subsequently be changed using the Ia_setup 
command. 

For all controller subclasses, the Hostid_cnt must be set to 6. Furthermore, for the 
iSBC 186/51, Hostid_loc0-5 should be set to 

0F0H, 0F2H, 0F4H, 0F6H, 0F8H, OFAH 

For the iSBC 550FW and iSBC 552 subclasses, Hostid_loc0-5 are undefined. 

For the general_82586 subclass controller, Hostid_loc0-5 should be set to the port 
locations where a default host id can be read, if available. Data link always tries to 
establish a default host id. Therefore, for the general_82586 subclass controller, any 
Hostid_loc0-5 parameters are treated as valid port locations to establish the default 
host id. 



3.5.8 DL_CONFIG 

This macro is used to initialize the communications controller and to provide some 
additional link characteristics. The format is as follows: 

% D L C N F I G (LinespeedO, L i nespeedl , Mc_number, Conf ig_cnt 

ConfigO, Configl, Config2, Config3, C o n f i g 4 , Config5) 



where 



LinespeedO- 1 specifies the physical channel transmission rate in bits per 

second. For example, if LinespeedO is 0000H and Linespeedl 
is 001 OH, the transmission rate is 100000H (approximately 
10 Mbps). 



3-20 



iNA 960 Data Link Layer 



Mc_number specifies the maximum number of multicast address bytes 

used. This number cannot exceed 60. 

Config_cnt specifies the number of significant configuration bytes in the 

6 word parameters (Config0-5). This parameter can be 
between and 12. 

Config0-5 are 6 words that have the same form as the argument field 

of the configuration command. Only the first Config_cnt 
bytes are significant. The remaining fields should be set 
toO. 

The default configuration has the following values: 

Linespeed0-1 = (0000H, 0010H) 

Mc_number = 60 

Config_cnt = 

ConfigO-5 = (0, 0, 0, 0, 0, 0) 

A Config_cnt of leaves the data link controller at its default configuration after 
power up. 

The DL_CONFIG macro allows the user to directly configure the 82586 communi- 
cations controller. The configuration argument (as determined by Config_cnt and the 
configuration words Config0-5) is passed straight through to the 82568 during 
initialization. This forms the argument of the Configure command of the 82586. See 
Appendix D or the 82586 Reference Manual and the iSBC 550 Ethernet Controller 
Kit Programmer's Reference for details on the argument fields of the 82586 Confi- 
gure command. The configurability of the 82586 running under iNA 960 has limita- 
tions. See Section 3.4.6. 

To better understand the configuration process during initialization, consider the 
following two cases. The first case is identical to the default and has the same affect 
as if no configuration were given (Config_cnt = 0). Here, the parameters are as 
follows: 

Config_cnt = 0CH 

Config0-5 = (080CH, 2600H, 6000H, F200H, OH, 2EH) 

The second case configures data link to run with No Carrier Sense. The parameters 
are as follows: 

Config_cnt = 0CH 

Config0-5 = (080CH, 2600H, 6000H, F200H, 8H, 2EH) 

The user should note that when two or more nodes are connected without carrier 
sensing, such as, when two nodes are connected using an Ethel cable, the Transmit 
With No Carrier Sense bit of the configuration argument should be set as in the 
second configuration example. 



3.5.9 DL_INTERNAL 

This macro configures the internal data link to run with the IEEE 802 protocol and 
the 82586 category of controllers. This macro has no arguments. A call to this macro 
has the following form: 

X DL_I N T E R N A L 
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3.6 Exception Codes 

For the procedure call interface, the location indicated by the Exception_pointer 
parameter is set to one of the following: 

EXPSOK, the procedure parameters are copied into corresponding RBs with 

no error detected. 

8004 EXPSERR, an error is detected when the procedure parameters are copied 
to the corresponding request blocks. 

For the request block interface, the Response field of the returned request block has 
the following values in data link: 

Failure. Reason not specified or unknown. 

1 Execution with no errors. 

2 Number of configuration information bytes exceeds maximum. 

4 Received packet overflow. The received packet requires more than 4 user 

receive buffers and therefore is truncated. 

6 Size of transmit packet exceeds maximum (1500 bytes). 

8 Invalid data link opcode. 

10 CONNECT/DISCONNECT command error. 

12 Subsystem not defined. 

14 Number of address bytes in command exceeds maximum. 

16 The 82586 reports that command execution is not OK. 
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4.1 iNA 960 Network Layer 

The network layer in iNA 960 Release l provides datagram delivery within a single 
network environment; no internetwork routing is provided. 

The network layer implements a zero-length protocol in which the network layer 
header consists of one byte with a value of zero. 

The network layer on iNA 960 is not accessible to the user. However, the network 
address defined below must be used when the transport services are used. 



4.2 Internet Address 

In iNA 960, the internet address consists of a 32-bit subnet identifier, a 48-bit Ether- 
net host identifier, and a 1 6-bit Network Service Access Point identifier (NASP ID). 
The length field is maintained so this internet address format can fit into the future 
"Variable Length Format" internet address scheme. The internet address described 
in Figure 4-1 is used at the network service interface point. iNA 960 does not use any 
internet address within the network protocol. 

The internet address must contain the following values: 

• Length (one byte) - OCH 

• Subnet ID (doubleword) - 01 H 

• Host ID (6 bytes) - the ETHERNET host address 

• NSAP ID (one word)- 01 H 

A requested Subnet ID other than 1 causes a "cannot reach" error response. 



ETHERNET 
HOST ID 



Figure 4-1 . iNA 960 Internet Address Implementation 
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CHAPTER 5 
THE TRANSPORT CONTROL LAYER 



5. 1 Transport Services 

The iNA Transport Service (iTS) provides message delivery services between user 
processes running on computers (network hosts or nodes) anywhere in an Intel 
Network Architecture (iNA)-compatible system. 

The user processes are identified by means of transport addresses (TAs). A TA consists 
of a Network Address (NA) and a Transport Service Access Point (TSAP-ID). The 
TSAP-ID identifies the access point between the user process and the iTS. 

The iNA Transport Service provides the following two types of services to the user: 

1. A reliable connection-oriented Virtual Circuit (VC) message delivery service 
between two transport addresses. 

2. A non-guaranteed connectionless datagram message delivery service between one 
transport address and one or several other transport addresses (multicast). 



5.1.1 Virtual Circuit Service 

The virtual circuit iTS uses the standard ISO 8073 Class 4 transport protocol, which 
provides the following services: 

• Reliable Delivery-Data is delivered to the destination in the exact order it was 
sent by the source, with no errors, duplicates, or losses, regardless of the quality 
of service available from the underlying network service. 

• Data Rate Matching (flow control)-The iTS attempts to maximize throughput 
while conserving communication subsystem resources by controlling the rate at 
which messages are sent. This is based on the availability of receive buffers at 
the destination and its own resources. 

• Process Multiplexing-Several processes can use the iTS simultaneously with no 
risk that progress or lack of progress by one process will interfere with other 
processes. 

• Variable Length Messages-Short or long messages can be arbitrarily submitted 
for transmittal without regard for the minimum or maximum Network Service 
Data Unit (NSDU) lengths supported by the underlying network services. 

• Expedited Data Service-Short, urgent messages can be transmitted ahead of the 
normal messages by bypassing the normal flow control mechanisms. 

The iTS provides these services by means of a connection or virtual circuit. Pairs of 
users set up the connection (connection establishment phase), transfer data (data 
transfer phase) and terminate or disconnect (connection disestablishment phase) the 
connection between themselves. 



5.1.2 Datagram Services 

The datagram iTS uses proprietary mechanisms to transfer data between user 
processes without setting up a connection. This service gives no guarantees of deliv- 
ery. Data can be lost or misordered. Data can be transferred at one time to a single 
destination or to several destinations (multicast). 
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5.2 Buffers 

Use of the iTS requires the passing of address information and data back and forth 
between the user and iTS. The address information and data transferred by the user 
to iTS must first be loaded into a user buffer memory area. Pointers, segment tokens, 
or buffer descriptors are then used to specify the location of the buffers. 

The three types of buffers used by iTS are the following: 

1 . The Transport Address Buffer 

2. Contiguous Buffers 

3. Non Contiguous Buffers 



5.2.1 Pointers and Tokens 

In iRMX, a buffer can be located by either a PL/M long pointer or by a segment 
token. If a segment token is used, the buffer must start at an 8086 paragraph bound- 
ary, and the token represents the base address (i.e., paragraph number). The offset 
is if a token is used. The iTS interface allows the specification of buffers by either 
pointers or tokens. 



5.2.2 Transport Address Buffer 

The user must tell the iTS the local and remote TAs between which a virtual circuit 
is set up or a datagram is transferred. Here the word local means point of reference. 
Remote refers to a node or end of a connection that is on the other end of the local 
node. 

A transport address consists of a Network Address (NA) defining the node and a 
TSAP-ID defining the point of access to a user process using iTS. At the local end, 
the NA is maintained by the network layer and is not needed by the transport layer. 
Thus, the iTS requires only the local TSAP-ID. However, iTS requires the complete 
remote TA (remote NA and remote TSAP-ID). 

The formats of NAs have not yet been standardized. The length of an NA depends 
on the underlying network service provided to the transport layer. The contents of 
the NA are transparent to the transport layer, but the length must be known to allocate 
memory to save this address. Similarly, the lengths and format of TSAP-IDs have 
not been standardized and depend on transport user conventions. However, the lengths 
of TSAP-IDs must be known to store them in memory. 

Thus, fundamentally, the iTS interface must allow for variable length NAs and TSAP- 
IDs in order to be flexible in the future. The method provided by iTS is to store these 
addresses in a user-defined buffer area, with a pointer to this area specified by the 
user to iTS. A single remote/local transport address pair is stored in a single contig- 
uous variable length buffer (the transport address buffer) as illustrated by the PL/M 
declaration in Figure 5-1. The first byte of the transport address buffer must be 
(for compatibility with future extensions of iNA). 

For any implementation, it is assumed that the user is aware of the lengths and formats 
of the network addresses used to specify the remote end nodes of a connection or a 
datagram data transfer. The length of the NA is loaded into the remote NA length 
field of the TA buffer. Enough space is allocated in the buffer to load the address. 

Similarly, user processes communicating via the transport service must agree on format 
and lengths of TSAP-IDs. The lengths are loaded into the appropriate TA buffer 
length fields, and enough buffer space is allocated to accommodate those TSAP-IDs. 
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DECLARE- Transport$addres5$buffer STRUCTURE ( 

Reserved BYTE, /« Must be set to Ot/ 

Loc$tsap$id$len BYTE , 

Loc$tsap$id ( 1 o c $ t s a p $ i d $ 1 e ti ) BYTE 

Rem$ne t $addr $ 1 en BYTE 

Rem$net$addr ( r e m $ n e t $ a d d r $ 1 e n ) BYTE, 

Rem$ t sap$ i d$ 1 en BYTE , 

Rem$tsap$id ( r e m $ t s a p $ i d $ 1 e n ) BYTE ) 



Figure 5-1 . Transport Address Buffer Structure 



Memory resource constraints impose limits on the lengths of the NA and TSAP-IDs. 
For any implementation, these limits can be specified by the user at system genera- 
tion time via the transport configuration parameters. 

With one exception, the NA and TSAP-IDs are transparent to the iTS. When all 
bytes of the NA - or all bytes of the TSAP-ID = 0, the NA or TSAP-ID is called 
unspecified. Otherwise, the NA or TSAP-ID is called fully specified. 

A complete TA (NA plus TSAP-ID) is designated as follows: 

1. Unspecified if both the NA and TSAP-ID are unspecified. 

2. Partially specified if the NA is unspecified but the TSAP-ID is fully specified. 

3. Fully specified if both the NA and TSAP-ID are fully specified. 

Although the network addresses are transparent to the transport, the specific under- 
lying network layer used by iNA 960 imposes restrictions on NA formats. 



5.2.3 Contiguous Buffers 

With the virtual circuit service, the transport protocol allows the optional transfer of 
a small amount (32 or 64 bytes) of user data during the connection establishment 
and disestablishment phases. If the user wishes to transfer data during these phases, 
the iTS interface requires that a single contiguous buffer block be allocated in user 
memory to send or receive the data. The lengths of the buffers depend on the command 
issued. The user refers to the start of the buffer via a pointer or iRMX segment 
token. 



5.2.4 Noncontiguous Buffers 

For the virtual circuit data transfer (during the data transfer phase) or datagram 
data transfer, the user may allocate multiblock noncontiguous buffers to hold the 
data. The buffers are referenced by a user buffer descriptor block. This will be either 
a special memory area in the procedural interface or part of a Request Block (RB) 
in the RB interface. In either case, the descriptor block will have the format specified 
by the PL/M declaration of Figure 5-2. 

The user may specify buffer locations via pointers or segment tokens. If tokens are 
used, the buffer must start on a paragraph boundary. For tokens, the user sets all the 
offset fields of the descriptor block to and loads all base fields with the token for 
each contiguous memory segment block. 
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DECLARE buffer$descriptor STRUCTURE 

n u m $ b 1 k s BYTE, 

b 1 oc k s ( num$ b 1 k s ) STRUCTURE( 

offset WORD , 

base WORD, 

length WORD)); 



Figure 5-2 . Buffer Descriptor Structure 



5.2.5 Post Receive Buffer Policies 
For Virtual Circuits 

The iTS relies on the user to post all receive buffers for data received from a remote 
TS via the virtual circuit service. iTS permits posting a buffer available only for a 
specific connection. Data received under another connection cannot use the buffer. 

The virtual circuit service supports both normal and expedited data services. Receive 
buffers for normal data are posted and maintained separately from receive buffers 
for expedited data. 

Normal (nonexpedited) data is presented to iTS for transmission as arbitrarily long 
messages called TSDUs. When the data is received by the remote Transport Service 
(TS), it is passed to the receive buffers posted by the user (if available). If a buffer 
is filled before the end of the TSDU, it is returned to the user. When the end of the 
TSDU is buffered, the buffer is returned even if it is not filled. Such a return buffer 
is marked EOM (End of Message) to indicate the end of the TSDU to the user. Thus, 
iTS guarantees that no more than one TSDU is returned in a user's buffer. 

For Datagrams 

iTS relies on the user to post all receive buffers for data received from a remote TS 
via the datagram service. iTS permits posting a buffer available only to a specific 
TSAP. Only datagrams addressed to that TSAP can use that buffer for passing data. 

The data in each datagram sent by the iTS is a self-contained entity. If the total 
datagram buffer space available for a TSAP is less than the length of the received 
datagram data, the datagram is discarded with no data buffered. Otherwise, the data 
is buffered. Data from one datagram can be buffered in one or more receive buffers 
posted. The buffer containing the last byte of data in the received datagram is marked 
' t eom ,, to the user. The EOM buffer is returned when the last data of the datagram 
is buffered, even if space remains in the buffer. Thus, a returned buffer can contain 
data from at most one received datagram. 

Datagram receive buffers are posted and maintained separately from virtual circuit 
receive buffers. 



5.3 Request Block Interface Commands 

This section gives a detailed description of all iTS commands and responses using the 
Request Block (RB) interface. As detailed previously in Section 2.2.3, the user issues 
an RB command by first allocating an RB memory segment. Then the user fills in 
the fixed format fields, fills in the opcode for the command, and formats the argument 
field according to the format prescribed for the command. Section 5.3.2 defines the 
formats of the argument fields for each iTS command. Four classes of iTS RB 
argument fields exist. These classes are referenced in Section 5.3.2 and are illustrated 
by Figures 5-3 to 5-6. 
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DECLARE 



open$rb$args 
reference 



STRUCTURE 
WORD ) ; 



Figure 5-3 . Open RB Argument Fields 



DECLARE connect ion$request$rb$args 
iso$readon$code 
reserved (4) 
ack$delay$estimate 
t a$buf f er $of f se t 
ta$buffer$base 
persistence$count 
abor t $ t imeout 
reference 
conn$class 
negot$options 
user$data$buf f er$of f set 
user$data$buffer$base 
user$data$len 



STRUCTURE ( 


BYTE , 


BYTE , 


WORD , 


WORD , 


WORD , 


WORD , 


WORD , 


WORD , 


BYTE , 


WORD , 


WORD , 


WORD , 


BYTE ) ; 



Figure 5-4 . Connection Request RB Argument Fields 



DECLARE s t a n da r d $ vc $ r b $ a r g s STRUCTUREC 

i50$rea5on$code BYTE, 

reserved (15) BYTE, 

reference WORD, 

conn$class BYTE, 

bu f $ 1 en WORD, 

num $ b 1 k 5 BYTE, 

block(num$blks) STRUCTURE 

offset 

b a s e 

length 



WORD , 
WORD , 
WORD ) ) 



Figure 5-5 . Standard VC RB Argument Fields 



DECLARE da t ag r am$ r b $a r g s STRUCTUREC 

reserved (4) BYTE, 

ta$buffer$offset WORD, 

ta$buffer$base WORD, 

tsap$class BYTE, 

buf$len WORD, 

num$blks BYTE, 

block(num$blks) STRUCTURE 

offset 

b a s e 

length 



WORD 
WORD 
WORD 



) ) 



Figure 5-6 . Standard VC RB Argument Fields 
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After iTS processes the RB, it is returned to the response mailbox specified in a fixed 
format field of the RB. iTS fills the fixed format response code field of the RB with 
a code indicating the result of the command. Section 5.3.2 specifies in detail for each 
command the response codes and their meanings. 



5.3.1 Command Description Conventions 

The remainder of this section is divided into subsections, one for each iTS command. 
Each command is described as follows: 



Command: 
Subsystem: 

Opcode: 



A short descriptive name for the command. 

The code the user must fill into the RB fixed format 
subsystem field. 

The symbolic name for the operation code that the 
user must fill into the RB fixed format opcode field. 
The numerical equivalent is defined in a PL/M 
INCLUDE file. 



RB Class: 



One of the four classes of argument fields that applies 
to this command. 



Input Arguments: 



Output Arguments: 



Function: 



A list with description of arguments that the user 
must input to the RB before sending the RB to iTS. 
The argument names coincide with the ones in 
Figures 5-3, 5-4, 5-5, or 5-6 depending on the RB 
argument field class. 

A list with descriptions of RB arguments that iTS 
sends back to the user. This includes a description of 
any returned buffers. 

A description of the operation performed by the 
command. 



Response Codes: 



A list of symbolic response codes returned by iTS to 
the user in the fixed format response code field of the 
RB. The meaning of each response code for that 
command is described. Numeric equivalents for the 
response codes are defined in a PL/M INCLUDE 
file. 



Several parameter default values or limits are implementation dependent. These 
implementation dependencies are resolved by the iTS system configuration procedure 
(see Section 5.5). 
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5.3.2 OPEN 

Command 

OPEN 

Subsystem 

40H (Virtual Circuit) 

RB Class 

Open (Figure 5-3) 

Input Arguments 

None 

Output Arguments 

Reference-(WORD) a value identifying the connection data base(CDB) allocated 
by this command. 

Function 

This is the first command that must be issued whenever a new virtual circuit (or 
connection) is opened. The use of an iTS virtual circuit or connection requires the 
allocation of a memory area called a Connection Data Base (CDB). 

All CDBs reside in memory on the same board that contains the communications 
software. The maximum number, max_cdbs, of CDBs allowed is specified as a 
configuration parameter. 

A CDB maintains the state of the connection. Via entries in the CDB, the iTS can 
keep track of the sequencing of send and receive data, maintain flow control status, 
and recover from unacknowledged data packets. 

The iTS user uses the connection by referencing the CDB using a 16-bit number 
called a connection endpoint identifier or reference. The reference is returned to the 
user when the CDB is allocated by this command. The iTS returns the reference to 
the user in the reference field of the open RB. The user then refers to the connection 
in other iTS commands as an input argument by using the reference value obtained 
here. 

The very first reference returned by the transport after system initialization is selected 
via a 16-bit random number generation scheme. Thereafter, new references returned 
are incremented by 1. When the 16-bit reference numbers overflow, the reference of 
zero is skipped. 

Response Codes 

ok$resp-The CDB was allocated and the reference returned. 
no$resource-Could not allocate any more CDBs. The reference is returned as 0. 
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5.3.3 SEND CONNECT REQUEST 

Command 

SEND CONNECT REQUEST 

Subsystem 

40H (Virtual Circuit) 

Opcode 

send$conn$req 

RB Class 

Connection Request (Figure 5-4) 

Input Arguments 

ta$buffer$offset~(WORD) The offset of a pointer to a TA buffer. The TA buffer 
must be loaded with addressing information specifying end TAs of the connection. 
The TAs must be fully specified. The offset is set to if an iRMX segment token 
points to the TA buffer. The length of the remote net address and local or remote 
TSAP-IDs must not exceed the limits specified in the system configuration or an 
addressing error occurs. Multiple connections can be requested from the same local 
TSAP, to the same remote TA, or between the same local TSAP/remote TA pairs. 

ta$buffer$base-(WORD) The base of a pointer to or of a segment token for a TA 
buffer. 

persistence count-(WORD) The number of times to retry an active connection attempt 
upon connection refusal before giving up. 

If the value equals 0, use default (configuration dependent) 
If the value equals 1 to OFFFEH (number of retries) 
If the value equals OFFFFH, (do not give up) 

abort$timeout (WORD) Specifies the retransmission timeout given in units of 
51 ms. 

If the value equals use default (configuration dependent) 
If the value equals 1 to OFFFEH, (timeout value) 
If the value equals OFFFFH, (do not timeout) 

reference^ WORD) Identifies the CDB this request applies to. 

conn$class-(BYTE) Set to 0. 

negotSoptions-(WORD) Specifies class of service and options requested for negotia- 
tion on this connection (see Reference 1 listed in the Preface): 

If the value set is 0, use the default options specified by the configuration parameter 
def_negot_options. 

If the value set is not 0, the user can specify the following options: 
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Break word up into 3 nibbles (1 = least significant) 

• Nibble 1 

If nibble if equals 0, use 7 bit sequential numbers 
If nibble 1 equals 2, use 31 bit sequential numbers 

• Nibble 2 

If nibble 2 equals 4, for class four service 

• Nibble 3: 

If nibble 3 equals 0, no expedited service but checksums are to be used. 

If nibble 3 equals 1, expedited service and checksums are to be used. 

If nibble 3 equals 2, no expedited service and no checksums are to be used. 

If nibble 3 equals 3, expedited service but no checksum are to be used during 

data transfer. 

The most significant bit of the word must be set for user-specified (non-default) 
negotiation options. 

user$data$buffer$offset-(WORD) The offset of a pointer to a contiguous 64-byte 
buffer. 

user$data$buffer$base-(WORD) The base of a pointer to or of a segment token for 
a contiguous 64-byte buffer. 

If both base and offset equal 0, no buffer is allocated and no transparent user data is 
sent with the request. If either base or offset is not 0, the buffer is assumed to be 
allocated. It must be loaded with to 32 bytes of user data to be sent with the request. 

user$data$len-(BYTE) Specifies the length of the user data. 

• If the value specified is to 32, 

• If the value specified is greater than 32, an error will occur. 



Output Arguments 

ack$delay$estimate-(WORD) will always be returned with 0. 

iso$reason$code-(BYTE) 

• The iso$reason$code equals 82H if the connection negotiation failed. That is, the 
request was accepted by the remote TS, but the local TS aborted the connection 
because the options the remote TS negotiated were unacceptable. 

• The iso$reason$code disconnects reason code if the connection was rejected by 
the remote TS. 

• The iso$reason$code equals otherwise. 

user$data$buffer-(CONTIGUOUS BUFFER) If the connection attempt was 
successful and a user buffer was allocated, the RB will return in its user buffer any 
data contained in the connection confirmation received from the remote TS. If the 
connection attempt was rejected by the remote TS and the local TS gives up, the RB 
will return in its user buffer up to 64 bytes of any data contained in the disconnect 
request from the remote TS. The received data overwrites any data that was in the 
buffer used for the original connection request. 

user$data$len-(BYTE) Set to the length of any data received in response to the 
connection request. 
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Function 

This command actively requests a connection to a fully specified remote TA using 
specified ISO connection negotiation options. It is assumed that a local CDB was 
allocated and a reference was returned to the user as a result of a previous OPEN 
command. The reference returned previously is specified in the current command to 
request the connection using the corresponding allocated CDB. 

The user can request a connection with or without transparent data. 

The user can ask that transport request the connection a specified number of times 
in spite of a rejection by the remote transport service. This retry count is the persist- 
ence count that the user specifies in the RB. When the number of retries exceeds the 
count, the local TS gives up and indicates connection rejection to the user. However, 
persistence is not invoked regardless of the count if the ISO reason code returned in 
the remote TS's rejection TPDU is either or 88H. Persistence is also not applied 
when the local user decides to close the connection while the transport is requesting 
the connection. 

This RB is returned to the user either upon detection of an error, upon connection 
establishment, or upon rejection and the local TS giving up. Thus, the receipt of this 
RB by the user serves as a connection confirmation or failure indication to the user. 

Response Codes 

ok$resp-The request was accepted by the remote TS, and the connection is now 
established in the data transfer phase. 

ok$closed$resp-The local user aborted the connection while the connection request 
was outstanding. 

conn$reject-The connection attempt was rejected by the remote TS, and the local TS 
gave up after the persistence count expired. 

negot$failed-The request was accepted by the remote TS, but the local TS aborted 
the connection because of a negotiation failure at the local end. 

loc$timeout-The request was unanswered and the retransmission timer timed out, 
aborting the connection attempt. 

illegal$req-Invalid negotiation options were specified, and the connection attempt 
was aborted. 

buffer$too$long-user$data$len was greater than 32, and the connection attempt was 
aborted. 

illegalSaddress-Invalid local or remote TAs were specified, or the network address 
length exceeds max_net_addr_len, or the local or remote TSAP-ID exceeds max_tsap 
id_len. 

dup$req-A request was already in progress for this reference or the connection was 
already established. 

network$error-A network layer error exists at the transport network interface. 

unknown$reference-The user-specified reference does not correspond to an allocated 
CDB. 
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5.3.4 AWAIT CONNECT REQUEST/TRAN 

Command 

AWAIT CONNECT REQUEST/TRAN 

Subsystem 

40H (Virtual Circuit) 

Opcode 

await$conn$req$tran 

RB Class 

Connection Request (Figure 5-4) 

Input Arguments 

ta$buffer$offset-(WORD) The offset of a pointer to a TA buffer. The TA buffer 
must be loaded with addressing information specifying the end TAs of the connec- 
tion. The remote TA may be fully specified, partially specified, or unspecified. If the 
remote TA is partially specified or unspecified, the TSAP-ID or network address 
length in the buffer must still be fully specified to those lengths used in the network. 
The contents field is filled with zeros up to the length for unspecified TSAP-IDs or 
network addresses. This offset is set to if the TA buffer is pointed to by an iRMX 
segment token. The lengths of the remote net address and local or remote TSAP-IDs 
must not exceed the limits specified in the system configuration or an addressing 
error occurs. Multiple connection requests can be accepted at the same local TSAP, 
from the same remote TA, or between the same local TSAP/remote TA pairs. 

ta$buffer$base-(WORD) The base of a pointer to or of a segment token for a TA 
buffer. 

abort$timeout-(WORD) Same as for SEND CONNECT REQUEST command. 

referenced WORD) Same as for SEND CONNECT REQUEST command. 

conn$class-(BYTE) Set to 0. 

negot$options-(WORD) Same as for SEND CONNECT REQUEST command. 

user$data$buffer$offset-(WORD) The offset of a pointer to a contiguous 64-byte 
buffer. 

user$data$buffer$base-(WORD) The base of a pointer to or of a segment token for 
a contiguous 64-byte buffer. 

If both the base and the offset equal 0, then no buffer is allocated and no transparent 
user data is expected with incoming connection requests. For this CDB, the local TS 
will respond to incoming connection requests that are without user data. 

If either the base or the offset does not equal 0, then the buffer is assumed to be 
allocated. The local iTS can accept user data with an incoming connection request. 
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If the iTS receives a connection request with user data and the request has compati- 
ble addressing and negotiation parameters, then the data will be passed to the user in 
this buffer when this RB is returned to the user. 



Output Arguments 

ack$delay$estimate-(WORD) Always 0. 
iso$reason$code-( BYTE) 

The iso$reason$code equals 

• The ISO disconnect reason code if the connection was aborted by the remote TS 
during the connection establishment phase. 

The iso$reason$code equals 

• otherwise. 

ta$buffer-(ADDRESS BUFFER) Contains within the remote TA fields the address 
of the remote TS user with which the connection was established. 

negot$options-(WORD) The agreed-upon negotiation options using the encoding 
defined for the SEND CONN REQ command. 

user$data$buffer-( CONTIGUOUS BUFFER) If data is to be returned from an 
incoming connection request, the data is returned to the user in this buffer. 

user$data$len-(BYTE) Set to the length of the user data returned. 



Function 

This command indicates that the iTS user is willing to consider incoming connection 
requests from a remote transport service. iTS itself will decide to accept or reject the 
request based only on addressing, negotiation option, and user data buffer availability 
information. The connection request is not passed to the iTS user for further consid- 
eration. The user thus pre-establishes its connection acceptance criteria with this 
command prior to any connection request received from a remote TS. This mecha- 
nism of pre-establishing the connection criteria is called passive open. 

It is assumed that a local CDB was allocated and a reference was returned to the 
user as a result of a previous OPEN command. The reference returned previously is 
specified in the current command to await connection requests using the correspond- 
ing allocated CDB. 

For this command, a remote TA is specified in either the fully specified, partially 
specified, or unspecified mode. The local TSAP-ID must be fully specified (not 0). 

By a series of these commands, a user can await connection requests. For an incom- 
ing connection request, the CDBs listening for requests via these commands are 
scanned. A request is matched to a CDB if the request passes the following tests 
described below: 

1 . Address match tests. 

2. Negotiation option tests. 

3. User data buffer availability test. 
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For the address match test, an await connection request may be fully specified, 
partially specified, or unspecified. 

• Fully specified (fully specified remote TA) means that only incoming connection 
requests from the exact remote TA specified will be considered. 

• Partially specified (partially specified remote TA) means that a connection request 
from any remote NA, but only one specific TSAP at that NA, will be considered. 

• Unspecified (unspecified remote TA) means that a connection request from any 
remote TA will be considered. 

A connection request passes the address match test only if all of the following condi- 
tions exist: 

• The await connection request command is issued prior to receipt of the connec- 
tion request, whose TA satisfies the remaining four requirements. 

• The lengths of the NA and TSAP-ID fields of the remote source TA in the 
incoming request equal the corresponding lengths specified in this command's 
TA buffer. 

• The remote source TA in the incoming request matches the local user remote TA 
specified in this command's TA buffer. 

• The length of the destination TSAP-ID in the incoming request equals the length 
of the local TSAP-ID defined in this command's TA buffer. 

• The destination TSAP-ID in the incoming request matches the local TSAP-ID 
defined in this command's TA buffer. 

The address match test is performed first for a received connection request. For 
multiple CDBs listening for connection requests, the matching attempt is done in the 
following order of decreasing precedence: 

• For a CDB with a fully specified remote TA in the TA buffer of this command. 

• For a CDB with a partially specified remote TA in the TA buffer of this 
command. 

• For a CDB with an unspecified remote TA in the TA buffer of this command. 

If the address match test fails for one CDB, then that CDB is skipped and the incom- 
ing connection request is checked against other CDBs. 

If an address match is found, a check is next made for compatible negotiation options 
as defined by the ISO standard. For incompatible options, the connection request is 
not matched to the CDB specified in this command and is checked against other 
CDBs awaiting requests. 

For compatible addresses and negotiation options, a check is made to see if the 
incoming request contains user data. If so, then the CDB must be expecting data as 
defined by this command (a nonzero pointer to the data buffer). If the CDB is not 
expecting data, the connection request with data is not matched to the CDB specified 
in this command and the incoming connection request with data is checked against 
other CDBs. If the CDB is expecting data, the incoming request is matched to it. 

If the incoming request has no data, then it is matched to the CDB if it passes address 
match and negotiation option tests. 

If the incoming request matches a CDB, then for passive open await connection 
requests the connection is immediately accepted for the request by the matched CDB. 
In this case, the RB is not returned until completion of the three-way handshake (see 
Reference 1 listed in the Preface) that establishes the connection. Thus, the return of 
this RB serves as a confirmation of connection establishment. Also, any user data 
received with the request is passed to the user on return of the RB. 
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However, if no awaiting CDB is found that matches the incoming connection request, 
then iTS will reject the connection request. In this case, the RB is not returned to the 
user. This permits iTS to await further connection requests that may be valid. 

Figure 5-7 presents a flow-chart summarizing the connection request consideration 
policy of iTS. For the passive open AWAIT CONNECT REQUEST command in 
which the request is not passed to the user, the "No" path is taken at the decision 
point, "Pass Request to User?" 

The user may rescind their willingness to listen for connection requests by issuing a 
CLOSE command with reference corresponding to the connection rescinded. This 
will delete the CDB and terminate use of the reference. 

Response Codes 

ok$resp-The request was accepted. The connection is now established in the data 
transfer phase. 

ok$closed$resp-The local user withdrew its willingness to listen for remote connec- 
tion requests. 

loc$timeout-The request was accepted but transport timed out before completion of 
the three-way handshake. The connection is aborted. 

rem$abort-The connection request was accepted by transport but the remote TS 
aborted the connection during the connection establishment phase. 

illegal$req-The user specified invalid negotiation options. The connection attempt 
was aborted. 

illegal$address-The user specified invalid TA address options or the local TSAP-ID 
or remote TA length exceeds the configuration limits. 

dup$request-This is a duplicate connection request. That is the transport is already 
awaiting a remote request or the connection is already established. 

network$error-A network layer error is reported at the transport/network interface. 

unknown$reference-The CDB corresponding to this reference is not allocated. 
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Figure 5-7 . Connection Request Consideration Policy 
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5.3.5 AWAIT CONNECT REQUEST/ USER 

Command 

AWAIT CONNECT REQUEST/USER 

Subsystem 

40H (Virtual Circuit) 

Opcode 

await$conn$req$user 

RB Class 

Connection Request (Figure 5-4) 

Input Arguments 

ta$buffer$offset-(WORD) The offset of a pointer to a TA buffer. The TA buffer 
must be loaded with addressing information specifying the end TAs of the connec- 
tion. The remote TA may be fully specified, partially specified, or unspecified. If the 
remote TA is either partially specified or unspecified, the TSAP-ID or network address 
length in the buffer must still be fully specified to those lengths used in the network. 
The contents field is filled with zeros up to the length for unspecified TSAP-IDs or 
network addresses. This offset is set to if the TA buffer is pointed to by an iRMX 
segment token. The length of the remote net address and local or remote TSAP-IDs 
must not exceed the limits specified in the system configuration, or an addressing 
error occurs. Multiple connection requests can be accepted to the same local TSAP, 
from the same remote TA, or between the same local TSAP/remote TA pairs. 

ta$buffer$base-(WORD) The base of a pointer to or of a segment token for a TA 
buffer. 

abort$timeout-(WORD) Same as for SEND CONNECT REQUEST command. 

reference-(WORD) Same as for SEND CONNECT REQUEST command. 

connSclass-(BYTE) Set to 0. 

negot$options-(WORD) Same as for SEND CONNECT REQUEST command. 

user$data$buffer$offset-(WORD) The offset of a pointer to a contiguous 64-byte 
buffer. 

user$data$buffer$base-(WORD) The base of a pointer to or of a segment token for 
a contiguous 64-byte buffer. 

If both base and offset equal 0, then no buffer is allocated and no transparent user 
data is expected with incoming connection requests. The local iTS will respond for 
this CDB only to incoming connection requests without user data. If either the base 
or offset does not equal 0, then the buffer is assumed to be allocated. The local iTS 
can accept user data with an incoming connection request. If the iTS receives a 
connection request with user data and the request has compatible addressing and 
negotiation parameters, then the data will be passed to the user in this buffer when 
this RB is returned to the user. 
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Output Arguments 

ack$delay$estimate-(WORD) 

• =0, always 

iso$reason$code-( BYTE) 

• =0, always 

ta$buffer-(ADDRESS BUFFER) Contains within the remote TA fields the address 
of the remote TS user with which the connection is being established. The local user 
can use this address information to partially base its decision to accept or reject the 
connection. 

negotSoptions-(WORD) The agreed upon negotiation options using the encoding 
defined for the SEND CONNECT REQUEST command. This permits the user to 
base its decision to accept or reject the connection partly on the new options 
negotiated. 

user$data$buffer-( CONTIGUOUS BUFFER) If data is to be returned from an 
incoming connection request, the data is returned in this buffer. The user can use this 
data to partially base its decision to accept or reject the connection. 

user$data$len-(BYTE) Set to the length of the returned user data. 



Function 

This command indicates that the iTS user is willing to consider incoming connection 
requests from a remote transport service. If the request has compatible addressing 
and negotiation option information, the request is passed to the user for further 
consideration. iTS will wait for the user's reply as to whether the connection was 
accepted or rejected. 

It is assumed that a local CDB was allocated and a reference was returned to the 
user as a result of a previous OPEN command. The reference returned previously is 
specified in the current command to await connection requests using the correspond- 
ing allocated CDB. 

For this command, a remote TA is specified in either the fully specified, partially 
specified, or unspecified mode. The local TSAP-ID must be fully specified (not 0). 

By a series of these commands, along with passive opens, a user can await connection 
request. For an incoming connection request, the CDBs listening for requests via this 
command or via passive opens' are scanned. A request is considered matched to a 
CDB if the request passes the following tests: 

1. Address match tests. 

2. Negotiation option tests. 

3. User data buffer availability test. 

These tests are identical to those used for a passive open. However, for this command, 
a matched request is not accepted immediately by iTS. Instead, the connection request 
is passed to the user for further consideration by returning the RB with the address- 
ing, negotiation option, and any user data information. iTS waits for the user's reply, 
which is one of the following: 

• ACCEPT CONNECT REQUEST command to accept the connection. 

• CLOSE command to reject the connection. 
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If no awaiting matches the incoming connection request, then iTS itself will immedi- 
ately reject the connection request. In this case, the RB is not returned to the user. 
This permits iTS to await further connection requests that may be valid. 

Figure 5-7 presents a flow chart summarizing the connection request consideration 
policy of iTS. For the user consideration AWAIT CONNECT REQUEST command 
in which the request is passed to the user, the "Yes" path is taken at the decision 
point "Pass Request to User?" 

Response Codes 

ok$decide$req$resp-The request is acceptable based on addressing, negotiation options 
and data buffer availability. The RB is being returned so that the user can decide 
whether to accept the connection. Transport awaits the user's response. 

ok$closed$resp-The local user withdrew their willingness to listen for remote connec- 
tion requests. 

illegal$req-The user specified invalid negotiation options. The connection attempt 
was aborted. 

illegal$address-The user specified an invalid TA, or the local TSAP-ID or remote 
TA length exceeds the configuration limits. 

dup$request-This is a duplicate connection request. That is, transport is already 
awaiting a remote request or a local response from the user for this reference. 

network$error-A network layer error is reported at the transport/network interface. 

unknown$reference-The CDB corresponding to this reference is not allocated. 



5-18 



iNA 960 The Transport Control Layer 

5.3.6 ACCEPT CONNECT REQUEST 

Command 

ACCEPT CONNECT REQUEST 

Subsystem 

40H (Virtual Circuit) 

Opcode 

accept$conn$req 

RB Class 

Connection Request (Figure 5-4) 

Input Arguments 

referenced WORD) Same as for SEND CONNECT REQUEST command. 

user$data$buffer$offset-(WORD) The offset of a pointer to a contiguous 64-byte 
buffer. 

user$data$buffer$base-(WORD) The base of a pointer to or of a segment token for 
a contiguous 64-byte buffer. This buffer (if allocated) should be loaded with any user 
data that will be sent with the connection confirmation signalling the remote TS that 
its connection request has been accepted. Only a maximum of 32 bytes can be trans- 
mitted. 

• If the offset or base equal 0, the buffer is not allocated. No data will be sent. 

• If the offset or base do not equal 0, the buffer is allocated. 

user$data$len-(BYTE) The length of the user data. 

• If the length of the data is to 32 bytes, no error occurs. 

• If the length of the data is greater than 32 bytes, an error occurs. 

Output Arguments 

ack$delay$estimate-(WORD) Always 0. 

iso$reason$code-(BYTE) 

• = disconnect reason code if the connection was aborted by the remote TS during 

the connection establishment phase. 

• =0, otherwise. 

ta$buffer-(ADDRESS BUFFER) Contains within the remote TA fields the address 
of the remote TS user with which the connection was accepted. 

negot$options-(WORD) The final agreed upon negotiation options, using the encod- 
ings defined for the SEND CONNECT REQUEST command. 
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user$data$buffer-(CONTIGUOUS BUFFER) Up to 64 bytes of data received from 
the remote TS if the connection was aborted remotely during the connection estab- 
lishment phase. 

user$data$len-(BYTE) The length of any returned data. 

Function 

With this command, the user indicates their acceptance of a transport connection 
specified by the reference. This command is the positive response to a previously 
returned AWAIT CONNECT REQUEST/USER RB. The user returns in the 
current command an optional buffer of user data to be sent with the connection 
confirmation. 

Response Codes 

ok$resp-The connection just became established on completion of the three-way 
handshake. 

ok$closed$resp-The local user aborted the connection before completion of the three- 
way handshake. 

loc$timeout-The local iTS timed out before completion of the three-way handshake. 
The connection was aborted. 

rem$abort-The remote TS aborted the connection before completion of the three- 
way handshake. 

buffer$too$long-More than 32 bytes of user data exist. The connection maintains its 
current state awaiting another local user response. 

dup$request-This is a duplicate connection response. That is, the transport already 
accepted the connection or the connection is already established. This error can occur 
if this call is made for a connection for which a connection request was not previously 
returned to the user. 

unknown$reference-The CDB corresponding to this reference is not allocated. 
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5.3.7 SEND DATA or SEND EOM DATA 

Command 

SEND DATA or SEND EOM DATA 

Subsystem 

40H (Virtual Circuit) 

Opcode 

send$data or send$eom$data 

RB Class 

Standard VC (Figure 5-5) 

Input Arguments 

referenced WORD) Same as for SEND CONNECT REQUEST. 

num$blks-(BYTE) The number of separate buffer blocks each block a contiguous 
memory area. This can be 0. 

block(i).offset-(WORD) The offset of a pointer to the start of the i th block. 

block(i).base-(WORD) The base of a pointer to or of a segment token for the i lh 
block. 

block(i).length-( WORD) The length of the data in the th block. 

Output Arguments 

iso$reason$code-(BYTE) 

• = ISO disconnect reason code if the RB was returned due to a remote abort. 

• =0 otherwise. 

Function 

With this command, the user requests the transmission of the data in the buffers 
using the normal delivery service of the specified connection. The normal delivery 
service uses the regular ISO flow control mechanisms. 

The SEND EOM DATA command signals that the end of the data marks the end 
of the Transport Service Data Unit (TSDU). 

Any number of the blocks may have zero length; there may also be zero blocks. A 
send request with zero bytes of data is allowed. If it is SEND EOM DATA, then an 
EOM (in ISO called EOT) signal will be sent. If it is SEND DATA, the message is 
null, so no data will be sent. The RB will be returned an indeterminate amount of 
time later, but always after the previous send request is returned and before any 
subsequent send requests are returned. 
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The sum total length of all- buffers pointed to by a single SENDSDATA or 
SEND$EOM$DATA RB is limited to a maximum value specified in Table 5-1. The 
65K (IK = 1000 bytes) limits are imposed by the WORD SIZE of the bufSlen field 
in the RB. The buffer size limitations for normal (7-bit) sequence number format 
ensure that the 7-bit (module 128) sequence number range is not exceeded for smaller 
max_tpdu-size_negotitated. 

The SEND DATA request can be made any time after issuing the initial OPEN 
command. Thus, iTS accepts SEND DATA requests even if the connection has not 
yet entered the established state. When a connection enters the established state, iTS 
transmits the corresponding transmit buffers in the order in which they are queued. 
Since iTS always attempts to send full Transport Protocol Data Units (TPDUs), it 
copies information from these transmit buffers into the TPDU without concern for 
the buffer or block boundaries. However, iTS guarantees that an EOM not only 
indicates the end of a message, but also the end of a TPDU. In other words, iTS 
never copies information from more than one message into the same TPDU. The 
remote receive buffers sizes need not match the transmit buffer sizes; progress in 
delivering data will be made as long as there is any receive buffer space at the other 
node. 

Response Codes 

ok$resp-All the buffers in the request have been successfully transmitted and 
acknowledged by the remote TS. 

ok$closed$resp-The local user aborted the connection and the queued RB is returned 
without transmitting its data. 

loc$timeout-The local iTS timed out without receiving an acknowledgment for some 
of the data in the request. 

rem$abort-The remote TS aborted the connection. 

illegal$req-The connection was closing or was already closed. 

no$resources-The CDB send queue is full. No more RBs can be queued until some 
already queued SEND RBs are returned. 

unknown$reference-The CDB corresponding to this reference is not allocated. 

Table 5-1 . Maximum Total Buffer Lengths 



max_tpdu_size negotiated 


Sequence Number Format 


7-Bit 


31-Bit 


7 (128 bytes) 

8 (256 bytes) 

9 (512 bytes) 

10 (1024 bytes) 

1 1 (2048 bytes) 


8K* 
16K 
32K 
64K 
65 K 


65K* 
65K 
65K 
65 K 
65K 



1K = 1000 bytes 
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5.3.8 RECEIVE DATA 

Command 

RECEIVE DATA 

Subsystem 

40H (Virtual Circuit) 

Opcode 

receive$data 

RB Class 

Standard VC (Figure 5-5) 

Input Arguments 

reference-(WORD) Identifies the CDB for which the receive buffer is being posted. 

conn$class-(BYTE) Set to 0. 

num$blks-(BYTE) The number of separate buffer blocks, each block a contiguous 
memory area to buffer the data. 

block(i).offset-(WORD) The offset of a pointer to the start of the i lh block. 

block(i).base-(WORD) The base of a pointer to or of a segment token for the i th 
block. 

block(i).length-(WORD) The length of the i th block. 

Output Arguments 

reference-(WORD) The reference is returned for the connection that used the buffer. 

iso$reason$code-(BYTE) Same as for SEND DATA command. 

buf$len-(WORD) The length of the data received in the buffers posted by this 
command. 

block$buffer-(NONCONTIGUOUS BUFFER) Contains the data received from the 
remote TS. 

Function 

By using this command, the user posts receive buffers for a specific connection. The 
buffers are used to store data received using the transport normal delivery service. 
This service is governed by the regular transport flow control mechanisms. 

The sum total length of all receive buffers pointed to by a single RECEIVE DATA 
RB must not exceed 65 K bytes. 

Buffers may be posted prior to establishment of the connection. 
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Response Codes 

ok$resp-All the buffers pointed to by the RB are filled with data and no EOM was 
signalled. 

ok$eom$resp-Transport signalled an EOM. The data in the buffers constitute the 
end of a TSDU. 

ok$closed$resp-The local user aborted the connection or the connection was closing 
on a user request when the buffer was posted. 

loc$timeout-The buffer was returned due to a connection timeout abort. 

rem$abort-The remote TS aborted the connection. 

no$resources-The CDB normal receive queue is full. No more normal receive buffers 
can be posted until some normal receive buffers already posted are returned. 

unknown$reference-The reference does not correspond to any allocated CDB. 
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5.3.9 SEND EXPEDITED DATA 

Command 

SEND EXPEDITED DATA 

Subsystem 

40H (Virtual Circuit) 

Opcode 

send$exp$data 

RB Class 

Standard VC (Figure 5-5) 

Input Arguments 

referenced WORD) Same as for SENDCONNREQ. 

num$blks-(BYTE) This must equal 1, because 16 bytes is the largest buffer permit- 
ted to be sent. 

block(0).offset-(WORD) The offset of a pointer to the start of the block. 

block(0).base-(WORD) The base of a pointer to or of a segment token for the block. 

block(0).length-(WORD) The length of the data in the block. The block length must 
be greater than but cannot exceed 16. 

Output Arguments 

iso$reason$code-(BYTE) 

• The iso$response$code equals the ISO disconnect reason code if the RB was 
returned due to a remote abort. (See Reference 1 listed in the Preface.) 

• The iso$reason$code equals 0, otherwise. 

Function 

With this command, the user requests the transmission of up to 16 bytes of data in 
the buffer using the expedited delivery service of the specified connection. 

With this service, the expedited data is guaranteed to arrive before any normal data 
submitted afterward. 

Response Codes 

ok$resp-The expedited data in the buffer was acknowledged. 
ok$closed$resp-The local user aborted the connection. 



5-25 



The Transport Control Layer «NA 960 



loc$timeout-Transport timed out without receiving expedited acknowledgement of 
the data. 

rem$abort-The remote TS aborted the connection. 

illegal req-Either expedited data requested to be transmitted but the service is not 
available on this connection or the connection was closing or was already closed. 

buffer$too$long-A user data length greater than 1 6 was specified or num$blks greater 
than 1, aborting the transmission. 

no$resources-The CDB expedited send queue is full. No more expedited send RBs 
can be queued at this time until some already queued expedited send RBs are returned. 

buffer$too$short-The buffer is empty. Either numSblks equals or the block length 
equals 0. 

unknown$reference-The specified reference does not correspond to an allocated CDB. 
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5.3.10 RECEIVE EXPEDITED DATA 

Command 

RECEIVE EXPEDITED DATA 

Subsystem 

40H (Virtual Circuit) 

Opcode 

receive$exp$data 

RB Class 

Standard VC (Figure 5-5) 

Input Arguments 

reference-(WORD) Identifies the connection data base for which the expedited receive 
buffer is being posted. 

connSclass-(BYTE) Set to 0. 

num$blks-(BYTE) Should be set to 1, because the data from the ED TPDU will be 
sent into the first block only. 

block(0).offset-(WORD) The offset of a pointer to the start of the first block. 

block(0).base-(WORD) The base of a pointer to or of a segment token for the first 
block. 

block(0).length-(WORD) The length of the first block. The length of the first block 
must be at least 16 bytes, because the buffer must be able to hold data from the 
longest ED TPDU having a maximum of 16 bytes. 

Output Arguments 

referenced WORD) Same as for RECEIVE DATA command. 

connSclass-(BYTE) Same as for RECEIVE DATA command. 

iso$reason$code-(BYTE) Same as for SEND DATA command. 

buf$len-( WORD) The length of the expedited data received in the buffers posted by 
this command. 

block$buffer-(NONCONTIGUOUS BUFFER) Contains the expedited data received 
from the remote TS. 
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Function 

By using this command, the user posts expedited receive buffers for a specific connec- 
tion. The buffers are used to store expedited data received using the transport 
expedited data delivery service. Expedited data bypasses the normal transport flow 
control mechanisms. (See Reference 1 listed in the Preface.) 

Each receive buffer can buffer data from only one ED TPDU received. Data from 
two or more ED TPDUs are not combined into one buffer even if data were to fit. 

The buffers for each request must be at least 16 bytes long to accommodate data in 
the largest ED TPDU that can be received. 

Expedited receive buffers may be posted prior to establishment of the connection. 

The queues of expedited receive buffers are maintained separately from the queues 
of normal receive buffers. 

Response Codes 

ok$eom$resp-The buffer is returned with expedited data from a single received ED 
TPDU. 

ok$closed$resp-The local user aborted the connection. 

loc$timeout-The connection terminated on a timeout. 

rem$abort-The remote TS aborted the connection. 

illegal$req-Expedited service not available. 

buffer$too$short-The length of the first buffer block posted with the request less 
than 16. 

no$resources-The CDB expedited receive queue is full. No more expedited receiver 
buffers can be posted until some that are posted are returned. 

unknown$reference-The reference does not correspond to an allocated CDB. 
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5.3.11 CLOSE 

Command 

CLOSE 

Subsystem 

40H (Virtual Circuit) 

Opcode 

close$req 

RB Class 

Standard VC (Figure 5-5) 

Input Arguments 

reference-(WORD) Same as for SEND CONNECT REQUEST 

iso$reason$code-(BYTE) The reason for the close using the ISO transport encodings 
given in the standard. (See Section 5.8.) 

num$blks-(BYTE) The number of separate buffer blocks with each block being a 
contiguous memory area. The blocks contain optional data that can be sent with the 
disconnect request to close the connection. Set to if no data is to be transmitted. 

block(i).offset-(WORD) The offset of a pointer to the start of the i th block. 

block(i).base-(WORD) The base of a pointer to or of a segment token for the i lh 
block. 

block(i).length-(WORD) The length of the data of the i lh block. The total length of 
data in all blocks cannot exceed 64. 

Output Arguments 

None 

Function 

With this command, the user requests the termination of an existing connection or 
the rejection of an incoming connection request. 

If the connection is already established, then this call initiates the ISO transport 
connection disestablishment procedure. Any normal or expedited data queued up to 
be sent will not be sent. However, the user may request up to 64 bytes of data to be 
sent with the disconnect request. This data will be processed by the receiver if a 
receive buffer is posted with an AWAIT CLOSE command. If the receiver had previ- 
ously issued an AWAIT CLOSE command, then any data received with the discon- 
nect request will be passed to the buffer allocated with that command along with the 
ISO reason code. Otherwise, disconnect request data will be discarded. 
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If a connection request was previously passed to the user to decide whether to accept 
the connection, this call signals transport that the connection request should be 
rejected. Data passed with this command can be sent to the remote TS to explain the 
reason for the disconnection. The iso$reason$code should be set to 88H to indicate 
that the connection request was refused. 

A CLOSE issued in response to a connection request or issued to abort an already 
established connection will delete the CDB. Any posted receive buffers (normal or 
expedited) or queued send requests (normal or expedited) will be returned to the 
user. An AWAIT CLOSE command will also be returned. The CLOSE RB will 
always be the final RB returned. 

If the connection is aborted by a remote TS, then any posted receive buffers, queued 
send requests, or AWAIT CLOSE RBs will be returned to the local user; and the 
CDB will be deleted. If there are no queued RBs to report the remote abort, the CDB 
will not be deleted, but will be marked "closed." The user can send one more RB 
command (SEND, RECEIVE, STATUS, DEFERRED STATUS, or 
AWAITSCLOSE) to determine the final status of the aborted connection. That RB 
will be returned with a rem$abort response code and the CDB will then be deleted. 
Any further requests on that connection will generate an unknown$reference error. 

Response Codes 

ok$closed$resp-For confirmed disconnection, disconnect collision, or if already closing 
or closed. 

ok$reject$conn$resp-For rejection of a connection requested. 

loc$timeout-If transport timed out without receiving a confirmation to its disconnect 
request. 

buffer$too$long-If a user data length greater than 64 was specified. 

unknown$reference-If the reference does not correspond to an allocated CDB. 
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5.3.12 AWAIT CLOSE 

Command 

AWAIT CLOSE 

Subsystem 

40H (Virtual Circuit) 

Opcode 

awaitSclose 

RB Class 

Standard VC (Figure 5-5) 

Input Arguments 

reference-(WORD) Same as for SEND CONNECT REQUEST. 

num$blks-(BYTE) The number of separate buffer blocks, each block a contiguous 
memory area, to receive disconnect request user data. Normally, this is set to one 
because a maximum of 64 bytes of data can be received from disconnect request; if 
no buffer is to be allocated. In this case, disconnect request user data will be ignored. 

block(i).offset-( WORD) The offset of a pointer to the start of the i th block. 

block(i).base-(WORD) The base of a pointer to or of a segment token for the i th 
block. 

block(i-).length-(WORD) The length of the i th block. 

Output Arguments 

reference-(WORD) The reference for the connection that was deleted. 

iso$reason$code-( BYTE) 

• = ISO reason code received in the disconnect request. (See Section 5.8.) 

buf$len-(WORD) The length of any user data received with the disconnect request 
which closed the connection. 

block$buffer-( NONCONTIGUOUS BUFFER) Contains the disconnect request user 
data received from the remote aborting TS. 

Function 

With this command, the user requests to be notified that a specified connection has 
terminated. 

A buffer (if allocated) can be returned to the user filled with data from a received 
disconnect request that may explain the cause of the disconnection. The user needs 
only to allocate a maximum of 64 bytes of buffer space to accommodate the longest 
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disconnect message permitted by the ISO standard. If the buffer length allocated is 
less than the received data length, then only the data that fits in the buffer is returned. 
The rest is lost. In particular, if no buffer is allocated, any disconnect data received 
is discarded. 

An ISO reason code is also returned to indicate the cause of the disconnection. 

Response Codes 

ok$closed$resp-The local user had aborted the connection or connection already 
closed. 

loc$timeout-The local transport service had timed out. 

rem$abort-A disconnect request was received from the remote TS on the specified 
connection. 

dup$request-Another AWAIT CLOSE command was posted previously on this 
connection. 

unknown$reference-The reference does not correspond to an allocated CDB. 
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5.3.13 SEND DATAGRAM 

Command 

SEND DATAGRAM 

Subsystem 

41 H (Datagram) 

Opcode 

sendSdatagram 

RB Class 

datagram (Figure 5-6) 

Input Arguments 

ta$buffer$offset-(WORD) The offset of a pointer to a TA buffer. The TA buffer 
must be loaded with addressing information specifying the source (local). 

TSAP-ID and destination (remote) TA of the datagram. The TAs must be fully 
specified. The remote NA can be multicase address. The lengths of the remote net 
address and local or remote TSAP-IDs must not exceed the limits specified in the 
system configuration or an addressing error occurs. 

ta$buffer$base-(WORD) The base of a pointer to or of a segment token for a TA 
buffer. 

num$blks-(BYTE) The number of separate buffer blocks, each block a contiguous 
memory area containing datagram data to be sent. 

block(i).offset-(WORD) The offset of a pointer to the start of the i th block. 

block(i).base-(WORD) The base of a pointer to or of a segment token for the i th 
block. 

block(i).length-(WORD) The length of the data in the i th block. The total length of 
all data over all blocks must be less than or equal to the maximum NSDU length 
provided by the network layer (minus a small overhead for the transport datagram 
header). For an IEEE 802.3 network layer and a 2-byte TSAP, the maximum length 
is 1486 bytes. 

Output Arguments 

None 

Function 

With this command, the user requests transmission of the data in the buffers using 
the transport datagram service. This service is connectionless and gives no assurance 
of delivery of the data. Data can be lost or misordered. 
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Transport datagram service does not provide a fragmentation/reassembly capability. 
Therefore, the length of the data cannot exceed the maximum NSDU size provided 
by the network layer. For an IEEE 802.3 network layer and a 2-byte TSAP, the 
maximum length is 1486 bytes. 

The destination transport address can be either a single station, multicast, or broad- 
cast network address. The multicast or broadcast network address conventions are 
transparent to the transport layer. They are dependent on the underlying network 
service used. 

Response Codes 

ok$resp-The data has been queued for transmission by the network layer. 
buffer$too$long-The data length exceeds the maximum NSDU size. 
illegal$address-The local TSAP-ID or remote TA exceeds the configuration limits. 
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5.3.14 RECEIVE DATAGRAM 

Command 

RECEIVE DATAGRAM 

Subsystem 

41 H (datagram) 

Opcode 

receiveSdatagram 

RB Class 

datagram (Figure 5-6) 

Input Arguments 

ta$buffer$offset-(WORD) The offset of a pointer to a TA buffer. The remote NA 
and TSAP-ID fields are not input parameters. However, the fields must be reserved 
to the proper length to buffer the source TA of a received datagram. 

The local TSAP-ID must be loaded into the buffer. The length of the local TSAP- 
ID must not exceed the limit specified in the system configuration, else an addressing 
error occurs. The local TSAP-ID which must be nonzero specifies the TSAP that 
posts the buffer. This posts the buffer on a queue reserved only for that TSAP-ID. 
Any received datagram with remote TSAP-ID matching the TSAP-ID of this queue 
can pass its data to the buffer. Datagrams with non-matching remote TSAP-IDs 
cannot use this buffer. 

ta$buffer$base-(WORD) The base of a pointer to or of a segment token for a TA 
buffer. 

tsap$class-(BYTE) Set to 0. 

num$blks-(BYTE) The number of separate buffer blocks, each block a contiguous 
memory area to receive datagram. 

data. block(i). of fset-( WORD) The offset of a pointer to the start of the i th block. 

block(i).base-(WORD) The base of a pointer to or of a segment token for the i th 
block. 

block(i).length-(WORD) The length of the i th block. 

Output Arguments 

ta$buffer-(ADDRESS BUFFER) Contains in the remote NA and TSAP-ID fields 
the remote source address of the received datagram. 

buf$len-(WORD) The length of the data received in the buffers posted by the 
command. 
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block$buffer-(NONCONTIGUOUS BUFFER) Contains the datagram data received 
from the remote TS. 

Function 

By using this command, the user posts a receive buffer on behalf of a TSAP to receive 
data from a transport datagram. The datagram buffer queues are maintained 
separately from the virtual circuit buffer queues. 

Response Codes 

ok$resp-The buffers pointed to by the RB are completely filled with data. 

ok$eom$resp-Buffer contains data to the end of the datagram. An RB can return 
data from at most one transport datagram. 

illegal$address-An addressing error detected. 

no$resources-No more resources to manage the buffers posted for the TSAP. 



5.4 Procedure Interface Commands 

The Transport Service procedural interface allows the user to invoke the transport 
commands via a set of procedure calls with parameters. The procedure calls are iRMX 
OS extensions. They provide a friendlier command interface to the iRMX user than 
the RB command interface. 

These procedure calls will create the request blocks defined from the user's procedure 
parameter list. As a result, iTS will return the RB to the user's response mailbox 
when iTS has processed the command. Thus the response interface is the same whether 
the procedural or RB command interface is used. 



5.4.1 Procedural Call Description Conventions 

Previously, Section 5.3.2 gives a detailed description of the procedure name and call 
arguments corresponding to each of the iTS interface commands defined in Section 
5.3. Because the procedural interface does not add any new functionality and the 
response interface is the same as the RB interface, no command function and response 
descriptions appear here. These are found under the headings "Output Arguments," 
"Function," and "Response Codes" for each command. 

The remainder of this section is divided into subsections, one for each iTS command. 
Each command is described as follows: 

COMMAND: Same name given for the RB interface. 

PROCEDURE: The name and parameter list of the interface procedure. 

PARAMETERS: Definition of the parameters of the procedure. Those param- 

eters that are identical in name with the input argument in 
the RB interface are used the same way as in the RB inter- 
face. Only those parameters that are different are described 
here. 

Each procedure also returns an exception code that usually indicates the status of 
parsing the parameter list for syntax. See Getting Started with the Release 5 iRMX™ 
86 System for a description of the exception codes. 
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5.4.2 OPEN 
Command 

OPEN 

Procedure 

CQ$TLVC$OPEN ( u 5 e r $ i d , r e s p o n 5 e $ m b x , except$ptr) 

Parameters 

user$id*-(WORD) user ID. 

response$mbx*-(WORD) iRMX response mailbox token 

except$ptr*-pointer to a word containing exception codes. 

These parameters are found in every procedure call. They are not described further. 
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5.4.3 SEND CONNECT REQUEST 
Command 

SEND CONNECT REQUEST 

Procedure 

,CQ$TLVC$SEND$CONN$REQ(ta$buffer$ptr, per5i5tence$count, 
abort$timeout, reference, conn$cla55, negotSoptions, 
user$data$buffer$token, user$data$len, user$id, 
responseSmbx, except $ptr ) 

Parameters 

ta$buffer$ptr-(POINTER) A pointer to a TA buffer. 

user$data$buffer$token-(WORD) An iRMX segment token for the connection 
request user data buffer. Set to only if no user data buffer is allocated. The user 
data buffer must be 64 bytes long if allocated. 
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5.4.4 AWAIT CONNECT REQUEST TRAN 
Command 

AWAIT CONNECT REQUEST TRAN 

Procedure 

CQ$TLVC$AWAIT$CQNN$REQ$TRAN(ta$buffer$ptr, 

persi5tence$count, abort (timeout , reference, conn$cla55, 
nego t $opt ions , user$data$buffer$token, user$data$len, 
user$id, response$mbx, except $ptr) 

Parameters 

ta$buffer$ptr-(POINTER) A pointer to the TA buffer. 
persistence$count-(WORD) Set to 0. 

user$data$buffer$token-(WORD) Same as for SEND CONNECT REQUEST. 
user$data$len-(BYTE) Set to 0. 
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5.4.5 AWAIT CONNECT REQUEST USER 
Command 

AWAIT CONNECT REQUEST USER 

Procedure 

CQ$TLVC$AWAlT$CONN$REQ$USER(ta$buffer$ptr, 

persi s tencetcount , abort$timeout, reference, conn$class, 
negotloptions, user$dat.a$buffer$token, user$data$len, 
userSid, responsetmbx, except $pt r) 

Parameters 

ta$buffer$ptr-(POINTER) A pointer to a TA buffer. 
persistence$count-(WORD) Set to 0. 

user$data$buffer$token-(WORD) Same as for SEND CONNECT REQUEST. 
user$data$len-(BYTE) Set to 0. 



5-40 



iNA 960 j|, e Transport Control Layer 

5.4.6 ACCEPT CONNECT REQUEST 
Command 

ACCEPT CONNECT REQUEST 

Procedure 

CQ$TLVC$ACCEPT$CQNN$REQ( reference, negot$options, 
user$data$buffer$token, user$data$len, userlid, 
respoTi5e$mbx, except$ptr) 

Parameters 

user$data$buffer$token-(WORD) Same as for SEND CONNECT REQUEST. 
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5.4.7 SEND DATA or SEND EOM DATA 
Command 

SEND DATA or SEND EOM DATA 

Procedure 

CQ$TLVC$SEND$DATA(reference, buff er$descr$ token , userlid, 
responselmbx, except $pt r) 

CQ$TLVC$SEND$EOM$DATA( reference, buffer $descr$ token, 
u 5 e r $ i d , re5ponse$mbx, except (ptr) 

Parameters 

buffer$descr$token-(WORD) An iRMX segment token for a buffer descriptor 
memory area formatted as shown in Figure 5-2. Prior to the call, the descriptor blocks 
must be filled in and the buffers pointed to must contain the data to be transmitted. 
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5.4.8 RECEIVE DATA 
Command 

RECEIVE DATA 

Procedure 

CQ$TLVC$RECE I VE$DATA( reference, c o n n $ class, 
buffer$descr$token, user$id, response$mbx, except$ptr) 

Parameters 

buffer$descr$token-(WORD) An iRMX segment token for a buffer descriptor 
memory area formatted as shown in Figure 5-2. Prior to the call, the descriptor block 
must be filled in. 
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5.4.9 SEND EXPEDITED DATA 
Command 

SEND EXPEDITED DATA 

Procedure 

CQ$TLVC$SEND$EXP$DATA(reference, user$data$buffer$tokeTi, 
user$data$len, u 5 e r $ i d , responselmbx, exceptlptr) 

Parameters 

user$data$buffer$token-(WORD) An iRMX segment token for the expedited data 
buffer. The procedural interface requires one contiguous buffer (max of 16 bytes). 
The buffer should be filled with the data to be transmitted prior to the call. 

user$data$len-(BYTE) The length of the data in the buffer (must be less than or 
equal to 16). 
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5.4.10 RECEIVE EXPEDITED DATA 
Command 

RECEIVE EXPEDITED DATA 

Procedure 

CQ$TLVC$RECE I VE$EXP$DATA( reference, c o n n $ class, 
u5er$data$buffer$token, user$data$len, useriid, 
responselmbx, except (pt r) 

Parameters 

user$data$buffer$token-(WORD) An iRMX segment token for the expedited data 
receive buffer. The procedural interface requires one contiguous buffer of length 
exactly 1 6 bytes. 

user$data$len-(BYTE) Set to 0. 
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5.4.11 CLOSE 
Command 

CLOSE 

Procedure 

CQ$TLVC$CLOSE(reference, i5o$reason$code, 
user$data$buffer$token, user$data$len, user (id, 
respoTi5e$mbx, except$ptr) 

Parameters 

user$data$buffer$token-(WORD) An iRMX segment token for an optional discon- 
nect user data buffer. This must be a contiguous buffer of length less than or equal 
to 64. Set to only if no buffer is allocated for no data with the disconnect request. 

user$data$len-(BYTE) The length of the data in the buffer to be sent (must be less 
than or equal to 64). 
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5.4.12 AWAIT CLOSE 
Command 

AWAIT CLOSE 

Procedure 

CQITLVCIAWA I T$CLDSE( reference, uaer$data$buffer$ token, 
user$data$len,u5er$id, respon5e$mbx, except $pt r) 

Parameters 

user$data$buffer$token-(WORD) An iRMX segment token for an optional discon- 
nect user data buffer. This must be a contiguous buffer of length less than or equal 
to 64. Set to only if no buffer is to be allocated for no data reception on receiving 
a disconnect request. 

user$data$len-(BYTE) Set to 0. 
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5.4.13 SEND DATAGRAM 
Command 

SEND DATAGRAM 

Procedure 

CQ$TLDG$SEND$DATAGRAM(ta$buffer$ptr, buffer$descr$ token, 
u 5 e r $ i d , responseSmbx, except )pt r) 

Parameters 

ta$buffer$ptr-(POINTER) A pointer to a TA buffer. 

buff er$descr$token-( WORD) Same as for SENDSDATA. The length of the data 
transmitted cannot exceed the maximum NSDU length provided by the underlying 
network service. 
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5.4.14 RECEIVE DATAGRAM 
Command 

RECEIVE DATAGRAM 

Procedure 

CQ$TLDG$RECEIVE$DATAGRAM(ta$buffer$ptr, t sap$c 1 as s , 
buffer$descr$token, user$id, responselmbx, 

excep t $p t r ) 

Parameters 

ta$buffer$ptr-(POINTER) A pointer to a TA buffer. 
buffer$descr$token-(WORD) Same as for RECEIVE $DATA. 
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5.5 Configuration 

To configure the Transport Layer configuration file, perform the following steps: 

1. Customize the Transport Layer to a particular implementation in the configu- 
ration file. 

2. Decide on which transport layer services are to be provided by an implementation 
and link the appropriate transport service modules at system generation time. 

3. For iRMX users decide whether to use the iRMX Transport Layer procedural 
interface and link the transport layer procedural library with the application job. 



5.5.1 Customizing the Transport Layer 

The iTS has several configuration parameters that customize the transport layer to a 
particular implementation. The seven classes of configuration parameters are as 
follows: 

1. Transport Address Limits 

2. Network Layer Interface Parameters 

3. Transport Data Base Parameters 

4. Client Request Default Parameters 

5. Internal Negotiation Option Parameters 

6. Retransmission Timer Parameters 

7. Flow Control Parameters 

The parameters in each class are defined in the following subsections. An assembly 
language configuration template is also specified. The configuration template models 
a typical iRMX subsystem configuration file that will be provided with the iTS 
software package. The configuration file contains default values that can be modified 
by a system implementor to customize the transport layer. The file is assembled and 
the resulting code is used to initialize the appropriate internal transport software 
variables. 



Transport Address Limits 

These parameters define the maximum lengths of the network address and TSAP-ID 
components of the transport address. 

Specifically, the parameters are as follows: 

• max_net_addr_len = Maximum network address length. Must be set to OCH. 

• max_tsap_id_len = Maximum length of local or remote transport service access 
point identifiers (TSAP-IDs). 

• max_nsap_id_len = Leave at default value of 2 



Network Layer Interface Parameters 

The only parameter in this class is the following: 

• loc_nsap id = The local network service access point (NSAP) - Id required to 
interface to the underlying network layer. Leave at default value of 1 . 
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Transport Data Base Parameters 

iTS requires a certain amount of RAM memory to maintain certain data structures 
used for its operation. As such, limits exist on the size or number of these data struc- 
tures. These limits are specified by the following parameters: 

max_cdbs = Maximum number of CDBs used to manage virtual circuits. Increase 
this parameter value to accommodate more concurrent connections. Each new 
connection requires about 200 bytes additional memory. 

max_conn_class = Maximum connection classes used to share receive buffers 
among connections. Leave at 0. 

max_datagram_tsaps = Maximum number of TSAPs that can have datagram 
receive buffers posted at one time. Set to if datagram service is not provided. 

max_tsap class = Maximum number of datagram TSAP classes used to share 
receive buffers among datagram TSAPs. Leave at 0. 

dg xsum_opt = Checksum Option Flag = if checksums not used. 0FFH if 
checksums are used. 

max_irbs = Maximum number of internal request blocks used to queue connec- 
tion related TPDUs for transmission. Leave at default value of 5. 

max_eirbs = Maximum number of internal request blocks used to queue connec- 
tion related expedited TPDUs for transmission. Leave at default value of 2. 

max_lirbs = Maximum number of long internal request blocks used to queue 
non-connection-related TPDUs for transmission. Leave at default value of 3. 

max_dirbs = Maximum number of internal request blocks used to queue 
datagram TPDUs for transmission. Leave at default value of 2. 



Client Request Default Parameters 

In the RB interface the user can specify that iTS use certain default values. The 
default values are the following configuration parameters: 

• def_persis = Default persistence count to specify the default number of retries 
to request a connection that is being rejected before giving up. 

• def_abort_to = The default abort timeout to specify the default length of time 
(in 51 -millisecond units) to retransmit before timing out and aborting a connec- 
tion due to a failure to acknowledge from the remote TS. 

• def_negot_options = The default connection negotiation options specified via the 
encoding. The default makes a choice for each of the following options. 

• Sequence number format (7- or 31 -bit). 

• Class of Service (only value of 4 supported). 

• Expedited Service/Checksum Options (Yes/No Combination). 

Internal Negotiation Options 

These concern options negotiated by the transport protocol during connection estab- 
lishment, but are not specified by the iTS user. The parameters are the following: 

• max_tpdu_size = Maximum TPDU size. 

• no_addit_opt_field = Additional option field used as an assumed additional option 
parameter that a remote TS requested, when, in fact, the request provided no 
such option parameter. 

• no_max_tpdu_size_field = Maximum TPDU size field used as an assumed 
maximum TPDU size that a remote TS requested, when, in fact, the request 
provided no size. 
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Retransmission Timer Parameters 

These parameters specify the characteristics of the iTS retransmission timer algorithm. 
These are used to fine tune the performance of the algorithm. The parameters are: 

• def_retran_to = Default retransmission timeout. This is the initial retransmis- 
sion timeout value used to start the retransmission algorithm for each connection. 
This retransrnission timeout sends Connection Requests (CR) or conn. confirm 
(CC) TPDUs. If CRs are to be passed to the user, the timeout should allow for 
the user to process requests. Specified in 1 00 microsecond units. 

• min_retran_time = Minimum retransmission time. This is the lower bound on 
the retransmission time computed by the algorithm to prevent excessive retrans- 
missions. Specified in 100 microsecond units. An inappropriate value can adversely 
affect performance. Too small a value will cause excessive retransmissions, creat- 
ing excessive network traffic and excessive CPU overhead to send and receive 
retransmitted TPDUs. Too large a value will waste time waiting to retransmit (if 
a retransmission is required). The default value provided gives adequate 
performance for several Intel data-communications processor boards and for IEEE 
802.3 local area networks. This parameter need only be retuned if performance 
degradation is observed in other hardware or network configurations. 

• closing_abort_to = Closing abort timeout. This is the total amount of time to 
keep trying to send a disconnect request in order to receive a disconnect confir- 
mation before closing the connection. Specified in 51 millisecond units. This 
parameter normally does not have to be changed. The value of this parameter 
could result in a delay (given by this time out in time units) to close a connection 
only if the remote TS has already disconnected. Otherwise, this parameter has 
no effect. 

• inactivity ak_retran_to = Inactivity AK retransmission timeout. This is the 
interval between flow control window AK TPDU transmissions when there is no 
other activity on a connection. Specified in 100 microsecond units. Leave this 
parameter at the default value. 

• max_inactivity count = Maximum inactivity count. This is the number of 
consecutive flow control window AK TPDUs that are sent without receiving any 
responses from the remote TS on a connection before considering the remote TS 
as disconnected and aborting the connection. The product max_inactivity_count 
and inactivity_ak retran_to parameters (converted to time) is the total length of 
time allowed by the transport without receiving TPDUs from the remote TS before 
assuming the connection is inactive and disconnected. Increase this count to 
increase effective inactivity timeout. Decrease this count to decrease the timeout. 

Flow Control Parameters 

These parameters specify the characteristics of the transport protocol flow control 
algorithm. The parameters are as follows: 

• max_window_size_normal = Maximum window size for normal (7-bit) sequence 
number format. The largest receive buffer credit that can be reported on a 
connection by the iTS to a remote TS for normal sequence number format. The 
maximum value for this parameter is 0FH, limited by the ISO 8073 Transport 
protocol. Do not use a larger value. This number actually affects transport layer 
performance. The value must be tuned as a function of the network layer buffer- 
ing capacity allocated in the BUFCFG.A86 macro. 

In BUFCFG.A86, the internal network buffering resources are specified. This 
limits the number of transport packets (called (TPDUs) that can be buffered at 
one time. For reasonable performance, the parameter max_window_size_normal 
value should be less than or equal to the maximum number of TPDUs that can 
be internally buffered, plus 3. For example, if 12 TPDUs can be simultaneously 
buffered by the network layer, then a reasonable value for this parameter is 1 5 
(decimal). 



5-52 



iNA 960 



The Transport Control Layer 



max window_size_extended = Maximum window size for extended (31 -bit) 
sequence number format. The largest receive buffer credit that can be reported 
on a connection by the Transport service to a remote TS for extended sequence 
number format. 

The value can be from to 65K. The same performance considerations are applied 
to this parameter as for the parameter max_window_size_normal. On any one 
connection either max_window_size_normal is used (if 7-bit sequence numbers 
are negotiated) or max_window_size_extended is used (for 31 -bit sequence 
number negotiation). 

min_credit = Minimum credit. The smallest receive buffer credit that can be 
reported on a connection by the iTS to a remote TS. Set to if the window can 
close. Set to 1 if the window never closes. If this parameter is set to to close the 
window, all the normal ISO 8073 flow control mechanisms will be invoked to 
open the credit window to prevent deadlock. If the value of min_credit equals 1, 
and the window is never reported as closed by the receiver (even if no buffers are 
available), these flow control window mechanisms never come into effect. The 
default (min credit = 1) actually enhances performance, because the ISO 8073 
open-window mechanisms incur substantial CPU overhead. The overhead can 
outweigh the performance improvements that might occur by a closed window 
preventing unnecessary retransmissions (to a receiver with no buffer). 

open_window_to = Open window timeout. This is the interval between succes- 
sive acknowledgements (AK TPDUs) that announce the opening of a previously 
closed credit window used to avoid flow control deadlock. Specified in 100 micro- 
second units. This parameter is not used if min credit equals 1. 

max_open_window_count = Maximum open window count. This is the maximum 
number of open window AKs that are transmitted before sender assumes that 
the remote TS has received the open window credit information. When this count 
is reached, the iTS stops transmitting the open window AKs. This parameter is 
not used if min_credit equals 1. 



5.5.2 Configuration Template 

The assembly MACROS required the parameters defined in the above sections. The 
INTEL supplied defaults are specified here. 



NAME TCONF 

t I NCLUDE (TL/TCONF .MAC) 

Transport Address Limits 

XTransport_Addre55_Limits(max net_addren,max tsap_id_len,max_n5ap_id_len) 
X'max_net_add_len=12 
X'max_tsap id_len=2 
% ' ma x_n s a p_i d_l e n = 2 

Network Layer Interface 

XNetwork_Layer_Interface(loc_ri5ap id) 
X ' 1 o c_n s a p__i d » 1 

Transport Data Bases 
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XConnection_limits(max_cdb5,max_corin_cla55) 

X'max c d b 5 = 2 1 

X ' ma x_c o n n_c 1 a 5 5 ■ 2 

X Da t a g r a m_s t r u c t u r e ( m a x d a t a g r a m_t 5 a p 5 , m a x tsap class, dg xsum_opt) 

X'max_datagram_tsap5=9 

X ' m a q x tsap c 1 a s s = 2 

X ' d g x s u m_o p t - 

Xinternal_request_blocks(max irbs,max_eirbs, maxi lirbs,max dirbs) 

X ' m a x_i r b s = 5 
X'max e i r b s = 2 
X ' ma x_l i r b s = 3 
X'max d i r b 5 = 2 

Client Request Defaults 

Xclient_reque5t_defaults(def_per5ist, def_abort_to, def_negot_options) 

X'def persi5t=1 

X ' de f_abo r t_t o = 180 H (about 5 min) 

X'def_negot_options=8242H 

X' 31bitseq,no 

X ' Class 4 

X' No expedited service/No checksums 

Internal Negotiation Options 

X i n t e r n a l_n e g o t_o p t i o n s (max_tpdu size, no addi t opt f ie Id , 

no_max_tpdu_5 i ze_f i e 1 d) 
X ' max_t pdu_5 i z e = B H (2048 bytes) 

X'no addit opt field=3 (expedited services and no checksum) 

X ' no_max_t pdu f i e 1 d = 7 (128 bytes) 

Retransmission Timer Parameters 

Xretran_timer(def_retran_to,min_retran_time,) 
X ' d e f_r e t r a n_t o = 1 , (1 second) 
X'min_retran_time»1000 (100 milliseconds) 
Xclo5ing_abort(closing_abort_to) 
X ' c 1 o s i n g_a b o r t_t o « 8 H (7 seconds) 

Xinactivity_timer(inactivity_ak_retran_to,max_inactivity count) 
X ' i n a c t i v i t y_a k_r e t r a n_t o = 3 , (30 seconds) 
X'max_inactivity count =8 



Flow Control 

Xwindow_5ize ( ma x_w i n d o w_s i z e_n o r m a 1 , m a x_w i n d o w_s i z e_e x t e n d e d , m i n_c r e d i t ) 

X'max_window_size_normal=OFH 

X ' m a x_w indow_size_extended = 0FH 

X'min c r e d i t = 1 

X o p e n_w indow_timer(open_windo w_t o,max_open_windo w_c o u n t ) 

X ' o p e n_w i n d o w_t o s 1 , (1 second) 

X'max_open_window_count=8 
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5.5.3 Configuring Transport Services 

The following sets of transport services can be configured at system generation time: 

• No transport services. The transport configuration file is not used. 

• Only the normal virtual circuit service. No expedited service and no datagram 
service. 

• Both the normal and expedited virtual circuit service. No datagram service. The 
expedited service is meaningful only if normal service is also provided. 

• Only the datagram service. No normal or expedited virtual circuit service. 

• All transport services including normal virtual circuit, expedited virtual circuit, 
and datagram services. 

5.5.4 iRMX™ Procedural Interface Configuration 

For iRMX applications using the iRMX Transport Layer procedural interface, one 
of the following library modules must be linked into the application job: 

• CQTLC.LIB: if the user program is compiled in COMPACT mode. 

• CQTLL.LIB: if the usr program is compiled in MEDIUM or LARGE mode. 

The user's application programs can make use of the following INCLUDE file to 
specify the external references to the iRMX Transport interface procedures: 

• CQTL.EXT 



5.6 Op Code/Response Code Include File 



Declare 



/♦Opcodes*/ 



open$req 

send$conn$req 

awai t$conn$req$traTi 

await$coriTi$req$u5er 

accept$conn$req 

5end$data 

send$eom$data 

receive$data 

wi thdraw$rcv$buf 

send$exp$data 

receive$exp$data 

wi thdraw$exp$buf 

close$req 

awai t (close 

statu5$req 

deflstatus 

reserved 

send$datagram 

receive$datagram 

withdraw$dg$buf 



L ITERA 
L I TERA 
L ITERA 
L ITERA 
ITERA 
ITERA 
ITERA 
ITERA 
ITERA 
ITERA 
ITERA 
ITERA 
ITERA 
ITERA 
ITERA 
ITERA 
ITERA 
ITERA 
ITERA 
ITERA 



LLY 
LLY 
LLY 
LLY 
LLY 
LLY 
LLY 
LLY 
LLY 
LLY 
LLY 
LLY 
LLY 
LLY 
LLY 
LLY 
LLY 
LLY 
LLY 
LLY 



1 ' , 


x 1 ' , 


* 2 ' , 


x 3 ' , 


M ' , 


* 5 ' , 


x 6 ' , 


* 7 ' , 


% 8' , 


l 9' , 


MO' 


Ml' 


M 2 ' 


M 3 ' 


M 4 ' 


M 5' 


M 6' 


M 7 ' 


x 1 8' 


* 1 9' 



Declare 



/♦Max opcode limits*/ 



vc$req$max 
first$dg$cmd 
r e q"$ m a x 



LITERALLY 
LITERALLY 
LITERALLY 



M 5 ' , 
M 7 ' , 
% 19' ; 
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Declare 



/♦Non-error Response Codes*/ 



o k $ r e s p 

ok$eom$resp 
ok$decide$req$resp 
ok$closed$resp 
ok$reject$conn$resp 



LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 



* 1 ' 
% 3 ' 
% 5 ' 

* 7 ' 
% 1 1 



Declare 



invalid$req 

no$resources 

unknown$reference 

buffer$too$short 

buffer$too$long 

illegal$req 

rem$abort 

loc( timeout 

unknown$conn$class 

d u p $ r e q 

conn$reject 

negot $f ai led 

i 1 1 egal (address 

network$error 

pro tocol $err 

illegal$rb$length 



I TE 
I TE 
I TE 
I TE 
I TE 
I TE 
I TE 
I TE 
ITE 
I TE 
I TE 
I TE 
I TE 
L I TE 
LITE 
LITE 



RALLY 
RALLY 
RALLY 
RALLY 
RALLY 
RALLY 
RALLY 
RALLY 
RALLY 
RALLY 
RALLY 
RALLY 
RALLY 
RALLY 
RALLY 
RALLY 



/♦Error Response Codes*/ 



* 2 ' , 


M ' , 


x e ' , 


x 8 • , 


MO' 


M 2 ' 


1 1 4 ' 


M6' 


M 8 ' 


* 2 ' 


x 22 , 


* 24 ' 


* 26 ' 


1 28 ' 


x 30 ' 


* 32 ' 



5.7 ISO Reason Codes 

Code Reason 

Reason not specified. 

1 Congestion at TSAP. 

2 Client entity not attached to TSAP. 

3 Address unknown. 

80H Normal disconnect initiated by client. 

81 H Remote TS congestion at connect request time. 

82H Connection negotiation failed (proposed classes not supported). 

83H Duplicate connection detected. 

84H Mismatched references. 

85H Protocol error. 

86H Not used. 

87H Reference overflow. 

88H Connection request refused on this network connection. 

89H Not used. 

8AH Header or parameter length invalid. 
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6.1 Overview 

The network management facility (NMF) supplies the network with planning, opera- 
tion, and maintenance functions. The planning capability gathers network usage 
information to help determine future expansion of the network. Operation deals with 
the normal, day-to-day network functions such as initialization, termination, 
monitoring and performance optimization. Maintenance performs the detection, 
isolation, amputation, and repair of network faults. 

The functions needed to implement all three goals of the NMF overlap considerably. 
For instance, both planning and maintenance need to access the layer databases. 
Similarly, the operation and maintenance functions must be able to bootstrap a remote 
node. For this reason, the NMF functions are grouped not by purpose, but by function. 

The functions afforded by the network management facility are layer management, 
debugging operations, down-line loading, dumping, and echo testing. 

Layer management provides the ability to examine and modify the internal databases 
of layers at both local and remote nodes. These databases include counters that 
indicate how the network is performing as well as network parameters affecting the 
throughput of the network. 

Debugging operations provided by the NMF are limited to the Read_memory and 
Set_memory commands. With these commands, the user can read or alter the memory 
of any host on the system. 

Down-line loading provides the capability of loading a set of remote nodes from a 
single host. This is done by a boot server module of the NMF. Besides offering boot- 
strap services, the boot server can be used to down-line load databases. 

Dumping is similar to down-line loading. A dump is initiated by a remote node issuing 
a dump command to the target node. The target then responds by transmitting a 
dump response packet that contains an image of the portion of memory requested. 

Echo testing allows a host to determine if a particular node is present on the network, 
and provides a test of the communication path to that node. Here, the NMF trans- 
mits a packet to the remote node and then listens for the node to echo it back. 

The NMF performs its operations on a remote node by communicating over the 
network with the NMF at the remote node. In general, this is done by using the 
transport control layers of each node to create a virtual circuit connection. For down- 
line loading and dumping, however, the approach is different. Down-line loading is 
used for booting systems. In particular, the system being loaded might be the commu- 
nication system itself. Similarly, dumping is used during debugging or when a fault 
is detected. Here, the operation of the transport control layer may be suspect. For 
these reasons, communication between nodes for these two commands is restricted to 
using just the raw data link facilities. 

The network management facility is configured using a configuration module as 
decribed in Chapters 8 and 9. This module consists of calls to NMF configuration 
macros detailed in this chapter. Most of these macros are used to configure a boot 
server into the local node. Stations that do not require the boot server can leave out 
these particular macro calls. 
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6.2 Addressing Conventions 

For most NMF commands, the user must specify the address of the node on which 
the command is to be performed. This is done by including a pointer to a buffer in 
memory. If the target node is a local node, this pointer should be 0. For remote nodes, 
however, there are two possibilities. In some cases, the buffer contains the standard 
6-byte Ethernet host address of the target. Otherwise, the buffer is in the format of 
the transport address buffer as shown below: 



Declare A d d r e s s_b u f f e r STRUCTURE ( 



Reserved 

L o c a 1_TS A P_i d_l e n 

Local_TSAP_i d 

Remote_net_addr_len 

R e m o t e_n e t_a d d r 

R em o t e_TS A P_i d_l e n 

R emo t e_TS A P_i d 



BYTE , 

BYTE , 

( Loca l_TSAP_i d_l en) BYTE, 

BYTE , 

( Remo t e_n e t_ad d r ) BYTE, 

BYTE , 

( Remo t e_TSAP_i d_l en) BYTE 



) ; 



where 

Reserved 

Local_TSAP_id_len 

Local_TSAP_id 

Remote_net_addr_len 

Remote_net_addr 

Remote_TSAP_id_len 

Remote TSAP id 



must be set to 0. 

is the length of the local TSAP id 

is a valid value for the local TSAP id. 

is the length of the remote network address. 

is a valid network address. 

must be set to 2. 

must be set to 3. 



Table 6-1 lists the NMF commands with the associated addressing convention used 
for each. Refer to Chapter 4 for further information regarding the transport address 
buffer. 



6.3 NMF Objects 

During the operation of the network, the network management facility keeps track 
of various parameters, called network management facility objects, for the local node. 
Any node on the system can read, clear, or change the values of the objects at the 

Table 6-1 . The NMF Commands and Their Addressing Conventions 



Command 


Address Convention 


Read_object 

Set_object 

Read_and_clear_object 


Transport address 
Transport address 
Transport address 


Read_memory 
Set_memory 


Transport address 
Transport address 


Forcedjoad 


Ethernet address 


Dump 


Ethernet address 


Echo 


Ethernet address 


Supply_buffer 
Takeback_buffer 


— 
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local node or at any of the remote nodes, by using the NMF commands Read_object, 
Read_and_clear_object, and Set_object. See Appendix B for detailed descriptions of 
the NMF objects. 

Objects are identified within a particular node by a two-byte id code. This code takes 
the following form: 



wxyzW 



where 
w 



is a digit that identifies the layer that the object belongs to. 
The values are as follows: 



1 Physical layer 5 

2 Data link layer 6 

3 Network layer 7 

4 Transport control layer 8 



Session layer 
Presentation layer 
Application layer 
Network management facility 



yz 



specifies the entity within the layer. For example, the trans- 
port layer hs two entities: the transport virtual circuit and the 
transport datagram services sublayers. These have a value of 
x that is and 1 respectively. 

identifies the particular object. 



Such a coding arrangement is designed for future expansion of the capabilities of the 
communication software. For the present release, however, only the following object 
categories apply: 



20yzH 
40yzH 
41yzH 
80yzH 



Data link layer objects. 
Transport layer virtual circuit objects. 
Transport layer datagram objects. 
NMF/ Boot server objects. 



Associated with each object is a modifier used in conjunction with the object to locate 
a particular object value. The meaning of the modifier can be different for different 
objects. In the current release of iNA 960, the modifier is ignored for data link and 
NMF objects. For the transport layer, however, a modifier of is used for connection 
independent objects. Connection dependent objects use the connection reference as 
the modifier. 



NMF objects fall into one of these classifications: 



Parameter 
Counter 



Statistic 
Value 



adjusts the actual operation of the layer. 

records the number of times a particular event occurs. A 
counter is an unsigned integer and can be either of the 
following types: 

wrap-around clears to on overflow. 

sticky sticks at "infinity" on overflow. 

is a time-averaged measure of some aspect of system 
operation. 

is none of the above. 
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6.3.1 NMF/ Data Link Objects 

Data link objects are provided that track the raw communication activity of the station. 
Included, are counters that monitor the total number of packets sent and received by 
the node. Collision activity is gauged by counters for primary and secondary colli- 
sions and for packets dropped due to excessive collisions. Finally, the rates of a number 
of different types of reception errors are tallied. These are CRC errors, where packets 
are dropped because the CRC code does not check; alignment errors, where a data 
boundary is not aligned at a byte boundary; and resource errors, where packets are 
dropped because no buffers are available for them. 

The following is a list of the data link objects along with their object id codes. For a 
complete description of each object, refer to Appendix B. 

2000H Data Link Type 

200 1H Line Speed 

2002H Host Id 

2003H Total Sent 

2004H Primary Collisions 

2005H Secondary Collisions 

2006H Exceeded Collisions 

2007 H Total Received 

2008H CRC Errors 

2009H Alignment Errors 

200AH Resource Errors 



6.3.2 NMF/Transport Layer Objects 

The transport layer objects included in iNA comprise objects of the virtual circuit 
subsystem and the datagram subsystem of the transport layer. The objects of the 
virtual circuit subsystem are further classified as either connection independent or 
connection dependent objects. For the connection dependent objects, the modifier of 
the object is used to specify the connection identifier. 

The transport objects include error counters, statistics, configuration parameters, and 
timeouts. The following is a list of the transport objects. See Appendix B for a detailed 
description of these objects. 

NMF/Transport Virtual Circuit Connection Independent Objects 

4000H Virtual Circuit Type 

400 lH Connection id Vector 
4002H ISO Transport Number 
4003H Maximum Connections 
4004H Current Maximum Connections 
4005H Maximum On-Board CDBs 
4006H ActiveCDBs 

4007H CDB Size 

4008 H Default Persistence Count 

4009H Default Abort Timeout 

400AH Default Retransmit Timeout 

400BH Minimum Retransmit Timeout 

400CH Closing Abort Timeout 

400DH Flow Control Window Timeout 

400EH Inactivity Maximum Count 

400FH Total Duplicate Segments Rejected 

401 OH Total Checksum Errors 
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401 1H Total Retransmissions 

4012H Total Resource Errors 

401 3H Maximum Network Address Length 

4014H Maximum TSAP-id Length 

401 5H Local NSAP-id 

4016H Reserved 

401 7H Reserved 

401 8H Default Connection Negotiation 

4019H Maximum TPDU Size 

401 AH No Additional Option Field 

401 BH No Maximum TPDU Size Field 

401 CH Maximum Normal Window Size 

401DH Maximum Extended Window Size 

401 EH Minimum Credit 

401 FH Open Window Timeout 

4020H Maximum Open Window Count 

NMF/Transport Virtual Circuit Connection Dependent Objects 

408 1H Local TSAP-id 

4082H Remote Network Address 

4083H Remote TSAP-id 

4084H Connection State 

408 5 H Remote Connection id 

4086H Persistence Count 

4087H Abort Timeout 

4088H Retransmit Timeout 

4089H Next Transmit Sequence Number 

408AH Duplicate Segments Rejected 

408BH Segments Retransmitted 

408CH Resource Errors 

408EH Client Options 

408FH Class Options 

408FH Additional Options 

4090H Maximum TPDU Size 

409 1H Maximum TPDU Data Length 

4092H Inactivity Count 

4093 H Reserved 

NMF/Transport Datagram Objects 

4100H Datagram Type 

4101 H Datagram Receive Queue Size 

4102H Reserved 

4103H Total Datagrams Transmitted 

4104H Total Datagrams Received 

4105H Total Datagram Resource Errors 

4106H Total Datagram Checksum Errors 

4107H Total Datagram Address Errors 



6.3.3 NMF/Boot Server Objects 

The objects of the network management facility are restricted to those that are used 
to configure the boot server. Most of these objects are determined at configuration 
time and may not be altered. The single exception is the boot table that may be 
changed dynamically during run time. This, in effect, changes the list of nodes that 
are recognized by the boot server. 
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The following is a list of the NMF/Boot server objects. See Appendix B for a detailed 
description of these objects. 

8000H NMFType 

8001 H Multicast Address 

8002H Maximum Number of Nodes 

8003H Maximum Number of Addresses 

8004H The Boot Table 

8005H Number of Class Codes 

8006H List of Class Codes 

80FFH Number of NMFs 



6.4 NMF Commands 

This section gives a brief introduction to the network management facility commands, 
followed by a detailed description of each command. 

As explained above, the network management facility manages the NMF objects that 
control the operation of the data link layer, transport layer, and the boot server. The 
NMF objects are viewed and modified with the following NMF commands: 

Read_object Returns the value of the given object. 

Set_object Sets the given object with the given value, if possible. 

Read_and_clear_object Returns the value of the given object and sets the object to 0, 
if possible. 

As a debugging aid, the NMF allows the user to read or set the memory of any node 
on the network using the following commands: 

Read_memory Downloads a given portion of memory from the remote node 

to the local node. 

Set_memory Loads the memory of the remote node with a given portion 

of memory from the local node. 

A particular node can force another node to initiate a down-line loading sequence 
with the following command: 

Forced_load Forces a given node to request a down-line load from the boot 

server. 

The following commands are used as debugging and maintenance aids: 

Dump Downloads a given portion of memory from the remote node 

to the local node using the raw data link facilities. 

Echo Sends a block of random data to a remote node that echoes 

the data back to the local node. 

The user may add new commands to the existing NMF commands. Commands that 
are not recognized by the NMF are forwarded to the user for dispensation. This is 
done using the following commands: 

Supply_buffer Supplies a user buffer to the NMF for storing an incoming 

packet with an unrecognized command field. 

Takeback_buffer Retrieves all outstanding Supply_buffer request blocks from 

the NMF. 
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6.4. 1 Read/ Set /Read_and_clear_object 

There are three commands available to interface with the objects of a layer: 
Read_object, Set_object, and Read_and_clear_object. In addition, each command 
may operate on several objects during a single invocation. 

To use one of these commands, the user sets aside two buffers in memory. A command 
buffer is used to specify the list of objects that are the subject of the command, and 
(for Set_object) to store the new object values. A response buffer is used to return 
the values read by the NMF. The user creates and fills in the command buffer before 
invoking the command. The response buffer is filled by the NMF after executing the 
command. The formats for these two buffers are specified later in this section. 

Command failure (such as no response from the remote station) is indicated by a 
code in the response field of the request block. In this case, nothing is written to the 
response buffer. However, if an attempt is made to clear an object that cannot be 
cleared or a nonexistent object is named, then the command is ignored only for that 
particular object. Thus, the number of object values in the response buffer may be 
less than the number specified in the command buffer. 

The procedure is different for the Set_object command. First, an attempt is made to 
set the object with the specified value. Then the value of the object is read and the 
result returned in the response buffer, even if the object cannot be set. 



Request Block Interface 

DECLARE Rb STRUCTURE ( 

Rb_header (6) WORD 

Layer BYTE , 

Opcode BYTE, 

Response WORD, 

T r a n 5_a d d r_p t r POINTER, 

Fill ed_l ength WORD, 

Resp_buf_p tr PO I NTER , 

R e 5 p_b u f_l e ng t h WORD, 

Cmd_bu f_p t r POINTER, 

Cmd_buf_l ength WORD ); 



Procedure Interface 



CQ$NML$READ$OB JECT ( C M D_b u f _p t r , C m d_b u f _1 e n g t h , 

R e s p_b u f _p t r , R e 5 p_b u f _1 e n g t h , T r a n s_a d d r_p t r , User, 
Retur n_m ailbox, Exceptio n_p t r ) 

CQ$NML$RE ADC$OBJECT ( C M D_b u f _p t r , C m d_b u f _1 e n g t h , 

R e s p_b u f _p t r , R e s p_b u f _1 e n g t h , T r a n s_a d d r_p t r , User, 
Return_mailbox, Except ion_p t r) 

CQ$NML$SET$OB JECT ( C M D_b u f _p t r , C m d_b u f _1 e n g t h , 

R e s p_b u f _p t r , R e s p_b u f _1 e n g t h , T r a n s_a d d r_p t r , User, 
Return_mailbox, Exception_ptr) 
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Command Parameters 



Op_code 



Response 



Trans_addr_ptr 

Filled_length 

Resp_buf_ptr 
Resp_buf_length 
Cmd_buf_ptr 
Cmd_buf_length 



One of the following: 

- Read_object 

1 - Read_and_clear_object 

2 - Set_object 

Set by the NMF after executing the command. Values are as 
follows: 

1 - OK response 

2 - no response from the remote node 

8 - error while trying to connect with remote NMF 

A - command not configured 

C - illegal request 

FFFE - command not configured 

A pointer to a buffer containing the transport address of the 
target node. 

The size, in bytes, of the buffer filled in by the NMF. This 
field is set by the NMF after executing the command. 

Points to the response buffer. 

The length of the response buffer. 

Points to the command buffer. 

The length of the command buffer. For commands on remote 
nodes, this must be less than 90 bytes. 



Command Buffer Format 



The format for the command buffer is the following: 



DECLARE CommaTid_buf f er STRUCTURE ( 



Number 

Dbj info 

Object 
Modifier 
Length 
Value 



BYTE , 

(Number) STRUCTURE ( 

WORD , 

WORD , 

WORD , 

(Length) BYTE )); 



where 

Number 

Object 

Modifier 

Length 

Value 



is the number of objects included in the buffer. 

is the id code for the given object. 

is a code used with some objects to select a particular value 
from within the given object. 

is the length, in bytes, of the Value field. Set to for the 
Read and the Read_and_clear commands. 

contains the new value of the object for the Set command. 
Ignored for the Read and Read_and_clear commands. 
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Response Buffer Format 

The format for the response buffer is the following: 

DECLARE Response_buf f er STRUCTURE ( 
Number BYTE , 



Obj info 

Object 
Modifier 
Length 
Value 



(Number ) STRUCTURE ( 
WORD , 
WORD , 
WORD , 
(Length) BYTE ) ) 



where 

Number 
Object 

Modifier 

Length 
Value 



is the number of objects included in the buffer. 

is the id code for the object. Only valid objects are returned 
by the NMF. In addition, objects that cannot be cleared are 
not returned during the Read_and_clear command. 

is a code used with some objects to select a particular value 
from within the given object. 

is the length, in bytes, of the Value field. 

contains one of the following: 

• the value of the given object for a successful Read or 
Read_and_clear command. 

• the value read back from the given object after an attempt 
has been made to set it (for a successful or an unsuccess- 
ful Set command). 
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6.4.2 Read/Set_memory 



As an aid to debugging, the network management facility provides the host 
with commands to read or set the memory of any node on the network. The 
Read/Set_memory commands to remote nodes use the services of the transport control 
layers at the two nodes. 



To use one of these commands, the user sets aside a buffer in memory. For the 
Read_memory command, this buffer is used to store the memory image retrieved 
from the target node. For the Set_memory command, this buffer contains the memory 
image that is loaded into the memory at the target node. 



Request Block Interface 



DECLARE Rb STRUCTURE ( 

Rb_header (6) WORD 

Layer BYTE , 

Opcode BYTE, 

Response WORD, 

T r a n 5_a d d r_p t r POINTER, 

Fill ed_l ength WORD, 

Buf f er_p t r POINTER, 

Buf f er_l eng t h WORD , 

Star t_addr POINTER 



Procedure Interface 

CQ$NML $RE AD$MEM (Start_addr, Buffer_ptr, B u f f e r_l e n g t h , 

Trans_addr_ptr, User, Return_mailbox, Except ion_p t r ) 

CQ$NML $SET$MEM (Start_addr, Buffer_ptr, B u f f e r_l e n g t h , 

Trans_addr_ptr, User, Return_mailbox, Exception_ptr) 



Command Parameters 



Op_code 



Response 



One of the following: 



Trans_addr_ptr 
Filled_length 



Read_memory 
Set_memory 



Set by the NMF after executing the command. Values are as 
follows: 

1 - OK response 

2 - no response from the remote node 

8 - error while trying to connect with remote NMF 

A - command not configured 

C - illegal request 

FFFE - command not configured 

Pointer to a buffer containing the transport address of the 
target node. 

Size, in bytes, of the memory area filled in by the NMF. This 
field is set by the NMF after executing the command. 
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Buffer_ptr Points to a buffer in memory that does the following: 

• contains the memory image read from the target node 
(Read_memory). 

• contains the memory image to be loaded into the target 
node (Set_memory). 

Buffer_length Length, in bytes, of the buffer selected by Buffer_ptr. If the 

target node is a remote node, this value must be less than 90. 

Start_addr Pointer containing the starting address in the memory of the 

target node where the operation is to be performed. 



6-11 



Network Management Facility 



iNA 960 



6.4.3 ForcecMoad 

Any node on the network may make a down-line load request from the boot server 
using the handshake procedure described in the iNA 960 Architecture Reference 
Manual. In addition, a node may force another node to initiate a down-line load 
sequence. This is accomplished with the Forced_load command. 

When the local NMF receives the Forced_load command, it transmits a packet 
containing the Forced_load command and a class code for the boot request. This is 
done using only the raw data link services. The NMF then waits for the remote node 
to return a Forced_load response packet. If there is no response, the NMF tries two 
additional times before assuming that the node is not responding. 

Request Block Interface 



DECLARE Rb_f orced_load STRUCTURE ( 



R b_h eader 

Layer 

Opcode 

Response 

D a t a 1 i n k_a d d r. 

C 1 a s 5_c ode 



.p t r 



(6) WORD , 
BYTE , 
BYTE , 
WORD , 
POINTER, 
WORD ) ; 



Procedure Interface 

CQ$NML$FORCE $L0AD (Class_code, D a t a 1 i n k_a d d r_p t r , User, 
Re tar n_m ailbox, Exceptio n_p t r ) 

Command Parameters 



Op_code 
Response 



Datalink_addr_ptr 
Class_code 



7 

Set by the NMF after executing the command. Values are: 

1 - OK response 

2 - no response from the remote node 
A - command not configured 

C - illegal request 

FFFE - command not configured 

Pointer to a buffer containing the data link address of the 
node that should request a down-line load. 

Class code used in the down-line load request. 



6-12 



iNA 960 



Network Management Facility 



6.4.4 Dump 

The NMF provides the facility to enable a node to get a dump of the memory of a 
remote node. This is done with the Dump command. Upon receiving this command, 
the NMF transmits a packet containing the dump command and waits for the remote 
node to return a dump response packet. If the remote node does not respond, the 
NMF tries an additional two times before assuming that the remote node is not 
responding. 

To use the Dump command, the user sets aside a buffer in local memory. In addition, 
the user specifies a starting address in the memory of the remote node. The memory 
image returned begins at this starting address and is no larger than the buffer speci- 
fied by the command. The maximum size of the memory image that can be returned 
is 1489 bytes. 

The Read_memory and Dump commands are similar in their operation. The differ- 
ence, however, is that Read_memory uses the services of the transport control layer 
to perform the communication between the nodes. Dump uses only the raw data link 
services. 



Request Block Interface 

DECLARE Rb_dump STRUCTURE ( 

Rb_header (G) WORD 

Layer BYTE , 

Opcode BYTE, 

Response WORD, 

Da ta 1 i n k_addr_p t r POINTER, 

Fill ed_l eng t h NORD , 

Buf f er_p tr POINTER, 

Bu f f e r_l ength WORD, 

Star t_addr WORD ) ; 



Procedure Interface 



CQ$NML$DUMP (Star t_addr 
Datal ink_addr_ptr , 



Buffer_ptr, Buffer_length, 
User, Return_mailbox, Exception_ptr) 



Command Parameters 



Op_code 
Response 



Datalink_addr_ptr 
Filled_length 



Set by the NMF after executing the command. Values are as 
follows: 



A 
C 
FFFE 



- OK response 

- no response from the remote node 

- received packet has wrong packet length field, 
indicating a breach of the IEEE 802 data link 
specifications by the remote node 

- command not configured 

- illegal request 

- command not configured 



Pointer to a buffer containing the data link address of the 
target node. 

Size, in bytes, of the memory area filled in by the NMF. This 
field is set by the NMF after executing the command. 
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Buffer_ptr Pointer to a buffer in memory where the NMF is to store the 

requested memory image. 

Buffer_length Length, in bytes, of the buffer selected by Buffer_ptr. 

Start_addr Pointer containing the starting address in the memory of the 

target node of the memory image that is requested. 
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6.4.5 Echo 

Echo service is used to determine if a given node is present on the network, to test 
the communication path to the remote node, and to ascertain the viability and 
functionality of the remote station. 

To use the command, the user specifies the address of the remote node along with a 
count value. The NMF then transmits a packet containing the echo command with a 
block of random data. The size of this block is that specified by the count value. The 
local NMF then waits for the remote node to return the response packet. If the remote 
node does not respond, the NMF tries an additional two times before assuming that 
the remote node is not responding. 

Upon receipt of the response packet, the local NMF determines whether the returned 
block of data is the same as the transmitted block. Thus, the echo command tests 
both the existence of the remote node on the network and the viability of the node. 

Request Block Interface 



DECLARE Rb_echo STRUCTURE ( 



R b_h eader 

Layer 

Opcode 

Response 

D a t a 1 i n k_a d d r. 

T r a n s m i t_d a t a. 

Receive d_d a t a. 



.p t r 

.count 

.count 



(6) WORD , 
BYTE , 
BYTE , 
NORD , 
PO I NTER , 
WORD , 
WORD ) ; 



Procedure Interface 

CQ$NML$ECHO (Transmit_data_count, Datalink_addr_ptr, User, 
Return_mailbox, Except ion_p t r ) 

Command Parameters 



Op_code 
Response 



Set by the NMF after executing the command. Values are as 
follows: 



1 - OK response 

2 - no response from the remote node 

6 - transmitted data and received data do not match 

A - command not configured 

C - illegal request 

FFFE - command not configured 

Datalink_addr_ptr Pointer to* a buffer containing the data link address of the 
target node. 

Transmit_data_count Number of bytes to be transmitted in the echo command 
packet. 

Received_data_count Number of bytes present in the echo response packet. 
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6.4.6 Supply/Takeback_buffer 

When a packet is received with the DLSAP of the NMF (the DLSAP of the NMF 
is 8), the command field is first examined to determine if the NMF recognizes the 
command. If it does, the NMF executes the command. If not, the packet is forwarded 
to the user for dispensation. In this way, the user may add NMF commands to those 
that already exist. 

This procedure can be employed by users who wish to write their own boot server 
modules. Here, the vendor-supplied boot server is not configured into the system. 
Then, the NMF no longer recognizes the boot request and boot data request 
commands. These are instead forwarded to the user to process. The user can then 
generate the appropriate response packet, using the services of the iNA 960 data link 
layer. 

When processing a packet that contains an NMF command to be forwarded, the 
NMF needs a buffer to store the packet. This is supplied to the NMF by the user via 
the Supply_buffer command. If a packet is received with no buffer available, the 
packet is dropped. If the size of the buffer is smaller than the length of the received 
packet, only the initial part of the packet is copied into the buffer. 

Buffers given to the NMF to store incoming packets remain with the NMF until a 
packet with an unrecognized command field is received. Thus, unlike other commands, 
there is no time limit for the Supply_buffer request block to be returned to the user. 

Occasionally, the user needs all outstanding buffers to be returned. This is accom- 
plished by issuing the Takeback_buffer command. Upon receipt of this command, all 
Supply_buffer request blocks are returned to the user (with a response code of 3, OK 
takeback response) followed by the Takeback_buffer request block. 

Supplyjbuffer RB Interface 

DECLARE Rb_supp 1 y_b u f f er STRUCTURE ( 

Rb_header (6 ) WORD , 

Layer BYTE, 

Opcode BYTE, 

Response WORD, 

Fill ed_l ength WORD , 

Buf f er_p t r POINTER, 

Buf f er_l ength WORD) 

Takeback_buffer RB Interface 

DECLARE Rb_t a k ebac k_buf f er STRUCTURE ( 
Rb_header (6) WORD , 

Layer BYTE , 

Opcode BYTE, 

Response WORD) 

Procedure Interface 

CQ$NML$SUPPL Y$BUF (Buffer_ptr, Buf fer_l ength , User, 
Return_mailbox, Except ion_p t r ) 

CQ$NML$TAKEBACK$BUFFER (User, R e t u r n_m a i 1 b o x , E x c e p t i o n_p t r ) 
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Command Parameters 



Op code 



Response 



FillecLlength 

Buffer_ptr 

Buffer_length 



One of the following: 

8 - Supply_buffer 

9 - Takeback_buffer 

Set by the NMF after executing the command. The values 
are as follows: 

SUPPLY_BUFFER 

1 - OK response; buffer contains a packet 

3 - OK response; buffer is returned in response to a takeback 

command 

4 - received packet has wrong packet length field, indicating 

a breach of the IEEE 802 data link specifications by the 

remote node 
C - illegal request 
E - buffer too small; buffer must be at least 14 bytes 

TAKEBACK_BUFFER 

1 - OK response 
C - illegal request 

Size, in bytes, of the memory area filled in by the NMF. This 
field is set by the NMF after executing the command. 

Pointer to the buffer in local memory offered by the 
Supply_buffer command. 

Length, in bytes, of the buffer selected by Buffer_ptr. 
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6.5 Down-Line Loading 

The network management facility provides the means for downloading remote systems. 
Usually, this feature is implemented to boot various stations. Individual stations 
without mass storage can use it to boot themselves, or a station can force other remote 
stations to boot or reboot. In particular, the down-line loading facility can be used to 
boot a set of nodes with the same version of software. Implementations of this facility 
are not restricted to booting operations, however. Down-line loading can also be used 
to load a database from (or to) a remote node. 

A down-line loading operation requires the cooperation of two stations. The node that 
is to be loaded is called the target station. The node that supplies the required data 
is called the executor station. At the time of a down-line load request, the target 
station may be in a state that can use only minimal data link facilities. For example, 
it may be the COMM system itself that is to be loaded. For this reason, the two 
stations communicate by a primitive protocol that uses only the raw data link 
facilities. 

The process that runs on the target station is called the boot consumer, and the process 
running on the executor station is termed the boot server. Because the two processes 
together provide a service that is general enough to be used for purposes other that 
booting, this terminology can be misleading. 

Down-line loading is conducted in the following way. The boot consumer transmits 
requests to the boot server and then waits for the boot server to respond. The response 
typically consists of some data and some control information. The control informa- 
tion informs the boot consumer how to interpret the data and whether more data is 
to follow. A typical boot sequence would consist of the boot consumer issuing a request 
for the first block of data; receiving a packet from the boot server; processing the 
packet; and then issuing a request for the next block of data. This sequence of events 
continues until the loading operation is complete. 

In addition to a remote node initiating its own down-line load, a third node may force 
the remote node to request down-line loading service. This is accomplished by the 
Forced load command. 



6.5.1 Class Codes 

Any request for a down-line load is accompanied by a class code for the request. 
Each class code determines the sequence of operations to be performed by the execu- 
tor station. Each operation can be either of the following: 

• A given named file is transmitted to the target station. 

• A user-written subroutine is executed by the executor station. 

Those files that are transmitted in response to a down-line load request must 
reside on the same device at the executor node. This device is specified by the 
Dev_info_block macro in the NMF configuration file. In addition, any modules 
transmitted have the following boot module format: 

DECLARE Boot_module STRUCTURE ( 
Command BYTE; 

L oad_add r DWORD; 

Length WORD; 

E x e c u t i o n_ad d r DWORD; 
Memory_image (*) BYTE ) 
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where 

Command 



Load_addr 
Length 

Execution_addr 
Memory_image 



indicates if the module is to be executed and if there are more 
modules to be loaded. Only the two low-order bits are 
meaningful and have the following values: 

bit = 1 another module is to be loaded (i.e., the current 
module is not the last one). 

bit 1 — 1 the execution address is to be called. 

bits 2-7 must be set to 0. 

specifies the first address where the data is to be placed. 

specifies the length of the memory image data. 

specifies the execution address of the loaded memory image. 

is the memory image to be transferred. This can be between 
and 2 16 — 1 bytes long. 



To include one or more subroutines in a down-line load request, a pointer for each 
subroutine is included in the class code definition. Each pointer indicates a location 
in the memory of the executor station that contains the entry address of the selected 
subroutine. 

These routines can transmit any additional data to the requesting station. The decla- 
ration of each routine is in the form: 

U 5 e r_b o o t_s u b r o a t i n e : PROCEDURE 

( H o 5 t_i d_p o i n t e r , Clas5_code, B 1 o c k_n u m b e r ) WORD; 

DECLARE 

H o 5 t_i d_p o i n t e r POINTER, /* Points to a buffer 

containing the host id 
of the remote node */ 
Clas5_code WORD, /» Class code of the remote 

station ♦/ 
B 1 o c k_n u m b e r WORD, /* Block number expected by 

the remote station »/ 
End U s e r_b o o t_5 u b r o u t i n e ; 

The WORD returned by the procedure specifies the block number expected by the 
remote node upon return from the procedure. 

In addition to being in the above format, each user-provided subroutine must follow 
these conventions: 

• The routine must follow the LARGE PL/M-86 model of computation. 

• The routine should not block for any reason. That is, it should not wait indefi- 
nitely at a mailbox, semaphore, etc. This is because execution of the entire 
communication system will not proceed until control returns from the subroutine. 

• The stack size available is 20 bytes. 

• The routine runs under the COMM job user id, that is, the same user id as the 
boot server and the rest of the communication system. 

• The routine must be loaded into memory by the user before the communication 
system starts execution. 
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As an example, a class code might specify the following sequence of events: 

1. Transmit file 'ABC. 

2. Call subroutine 'boot_A\ 

3. Transmit file 'XYZ'. 

The boot server sends the file 'ABC as a series of blocks with associated block 
numbers, say, 0-5. The boot server then calls the user subroutine 'boot_A'. The 
input parameter, Block_number, in this case is 6. If 'boot_A' does not send data to 
the boot consumer, the value returned from the procedure is 6. On the other hand, 
suppose 'boot_A' sends three blocks (6, 7, and 8) of data. Here, the value returned 
from the procedure is 9. Once the boot server has returned from procedure 'boot_A', 
the file 'XYZ' is split into blocks and transmitted to the boot consumer. The details 
of the protocol used between the boot consumer and the boot server are given in the 
iNA 960 Architecture Reference Manual. 

6.5.2 The Boot Table 

Upon initialization, the boot server boots any node that requests its service. During 
run time, the boot server can be reconfigured to service only a specified set of nodes. 
The list of node addresses for this set of serviceable nodes forms a dynamic object 
called the boot table. This is NMF object number 8004, and has the following struc- 
ture: 

DECLARE Boot_table STRUCTURE ( 
N um_Ti odes WORD, 

Nod.e_addreaa ( N u m_n o d e s ) STRUCTURE ( 
Addres s_by t e (6) BYTE ) ) ; 

Here, Num_nodes specifies the number of addresses in the boot table, each address 
being 6 bytes long. At initialization, the boot table has the following form: 

(1, OFFH, OFFH, OFFH, OFFH, OFFH, OFFH) 

The sole address in the boot table is the broadcast address. In this case, the boot 
server boots any node that requests its service. 

The boot table can be changed any time after initialization by performing the follow- 
ing steps: 

1. Create the structure Boot_table in the format shown above. This contains a list 
of the node addresses for the nodes to be included in the boot table. Only these 
nodes will be recognized by the boot server. 

2. Allocate a command buffer and a response buffer large enough to execute the 
Set_object command on NMF/boot server object 8004. 

3. Fill in the command buffer with the appropriate format, and include a copy of 
Boot_table. 

4. Execute the Set_object command on object 8004 using the command buffer. 

5. If the command was successful, check the response buffer to confirm that the 
boot table was set. 

The NMF does not check the contents of Boot_table. Thus, if 

Boot_table.Num_nodes = 6 

then there must be 6 addresses in the boot table, and the size of Boot_table must be 
38 bytes. 
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6.6 Configuring the Boot Server and the NMF 

Configuration of the COMM system is detailed in Chapters 7 and 8. As part of the 
configuration process, the user creates a network management facility configuration 
file, NMFCFG.A86. This file consists of calls to several configuration macros via 
user-supplied parameters. NMFCFG.A86 is then assembled and linked to the COMM 
system. 

The NMF configuration macros and their associated parameters are described in this 
section. Most of these macros are used to configure the boot server supplied with the 
system. If this boot server is not used, the boot server configuration macros are not 
included in the NMF configuration file. 



6.6. 1 Boot server multicast_address 

This macro takes the following form: 

XBoot_serve r_m ulticast_addres5 (Mult icas t.address) 

where 

Multicast_address is the multicast address of the boot server. 

Remote nodes requesting the services of the boot server issue packets containing a 
boot request and the multicast address of the boot server. This address is also used 
by a local boot consumer to locate a remote boot server. 

6.6.2 Max_nodes 

The boot server is initialized to boot any node that requests its services. Here, the 
boot table has the following value: 

(1, OFFH, OFFH, OFFH, OFFH, OFFH) 

During run time, the boot table (NMF/boot server object 8004) may be changed 
using the Set_object command. This restricts the boot server to recognizing boot 
requests from nodes specified in the boot table. The Max_nodes macro allocates space 
to hold the boot table by specifying the maximum number of node addresses that can 
appear in the boot table at one time. 

This macro takes the following form: 

%Max_nodes (Max_value) 

where 

Max_value is the maximum number of addresses in the boot table. The 

space reserved for this table is: 

(6 X Max_value) WORDS 
Max_value must be greater than or equal to 1. 
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6.6.3 Max^simultaneous boots 

Max_simultaneous_boots sets the upper bound for the number of boot consumers 
serviced at a single time by the boot server. This value should be as small as necessary 
to conserve resources. 

This macro has the following form: 

%Max_5imultaneou5_boot5 (Max_value) 

where 

Max_value is the maximum number of nodes that the boot server can 

boot at any one time. 

If the boot server is booting Max_value nodes and a new node requests service, the 
request is ignored. 



6.6.4 Class_code_info 

This macro has the following form: 

X C 1 a 5 5_c o d e_i n f o (File_name, F i 1 e_5 i z e ) 

where 

File_name is the pathname of a file containing the definitions of the class 

codes recognized by the boot server. 

File_size is the maximum size of File_name. 

The file specified in the Class_code_info macro is read by the boot server during 
initialization. This specifies the set of class codes the boot server recognizes and the 
associated list of files that are transmitted to the requesting station. The boot server 
only reads this file when it initializes. It does not modify this file in any way or read 
it at any other time. The user can, however, modify this file and then reboot the 
system if the file is changed. 

It is the user's responsibility to ensure that the actual size of File_name does not 
exceed the parameter File_size. In addition, it is important that the file specified in 
Class_code_info is in the format indicated by the following PL/M-style structure: 

DECLARE Cc_info STRUCTURE ( 

N u m_c 1 a 5 5_c o d e s BYTE, 

C 1 a 5 5_c o d e_5 p e c ( N u m_c 1 a 5 5_c o d e 5 ) STRUCTURE ( 

C 1 a 5 5_c ode NO RD , 

N um_e ntries BYTE, 

Entry (Num_ent ries) STRING )); 

Here, a STRING is a sequence of bytes, with the first byte specifying the number of 
bytes in the string. For example, the file iNA 960 would be represented as follows: 

7 , 'iNA 960 ' 

If the first byte is 0, it would normally indicate a null string. In this case, however, 
the entry is interpreted as a pointer, and the next 4 bytes are used as the value of the 
pointer. 
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When the boot server receives a boot request with a given class code, it runs through 
the list of entries for that class code in the order that they appear in the above file. 
For each entry that is a filename, the boot server transmits the specified file to the 
requesting station. When the entry is a pointer, the boot server uses the pointer as an 
entry to a subroutine and calls that subroutine. 

The class code information file (CC.INFO in the configuration file), must be in the 
format shown above. The following is an example of this file, described as a PL/M- 
style data type. 

C 1 a 5 s_c o de_i n f o («) DATA ( 

0002, /♦ The boot server recognizes 2 class codes. #/ 



1234H, /* The first class code is ' 1 2 34 H * . */ 

3, /* The boot server performs the following 3 steps * I 

12, ' / u 5 e r / i na96 ' , /* 1. Transmits the file ' / u s e r / i n a 9 G ' */ 

0, 2, 2F40, /* 2. Calls a subroutine at location 2 F 4 : 2 #/ 

16, ' /user/ ina960 , pat ' , /« 3. Transmits the file '/user/ina960.pat' 



t / 

4321H, I* The second class code is '4321H'. #/ 

1 , /* The boot server performs the following step * I 

12, ' / u s e r / i na9G0 ' ) I* 1. Transmits the file ' / u s e r / i n a 9 G ' *l 

Note that this file is not an ASCII file. For instance, the first entry in the file is a 
word with the value 2. The hex representation of the first two bytes in the file is 
02,00. The order is reversed because in a word field, the least significant byte gets 
placed before the most significant byte. The only ASCII entries in the file are the 
filenames, enclosed in apostrophes. (The apostrophes in the above example should 
not be included in the file. They are present to increase readability.) 



6.6.5 Device_info_block 

The Device_info_block macro specifies the physical device that contains all the files 
used by the boot server. When this macro is called, the boot server physically attaches 
the named device. This macro has the following form: 

% D e v i c e_i n f o_b 1 o c k ( L o g i c a l_n a m e , Device_name, File_driver) 

where 

Logical_name is the name for the connection that appears in the directory 

of the ROOT job. 

Device_name is the device unit that is used by the boot server. 

File_driver is NAMED. This is the only type of file the boot server 

expects to find. 

It is imperative that the class code definition file and all other files used by the boot 
server reside on the device specified in this macro. In addition, if a call to this macro 
is included in the NMF configuration, the associated call to the same macro should 
be removed from the configuration of the extended I/O system (EIOS), if used. 
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6.6.6 Nmf_cnfg 

This macro sets the configuration state of the network management facility. This 
can be used to restrict the services provided by the NMF. Commands such as 
Read_and_clear_object, Set_object, and Set_memory can be catastrophic if provided 
to normal users. By configuring only those services required by each user, system 
security is maintained and considerable memory is saved. 

The format for this macro is the following: 

XNmf_cnfg ( C n f g_5 t a t e , Rem_acce55) 



where 

Cnfg_state 



can be any of the following: 



- users cannot give commands to the NMF. The NMF 

only processes packets with the NMF DSAP Id. 

1 - in addition to the services provided by '0', NMF can 

operate on local objects, read/set memory of the local 
node, and perform the commands Echo, Dump, and 
Forced_load. 

2 - in addition to the services provided by T, the user can 

read objects and memory of remote stations. 

3 - in addition to the services provided by '2', the user can 

modify objects and memory of remote stations. 

Rem_access can be either of the following: 

- Remote stations do not have access to this station. 

1 - Remote stations do have access to this station. In this 

case, Cnfg_state must be greater than 0. 

The macro call NMF_cnfg (0, 1) is not allowed. 

Whenever a user issues a boot server request that is not configured into the system, 
the response code returned by the NMF is OAH or OFFFE - Exception, command 
not configured. 



6.6.7 Sample Configuration 



The file NMFCFG.A86 should contain the macro calls to configure the network 
management facility. If the boot server is to be left out or is written by the user, then 
he following macro calls must not be made: 

Max_nodes 

Max_simultaneous_boots 

Class_code_info 

Device info block 
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The following example of an NMF configuration file, NMFCFG.A86, configures the 
boot server as well as the NMF. 

NAME NMF_CNFG_MACROS 

$ INCLUDE ( : SD : C0MM/C0NF I G/NMFCFG. MAC ) 

XBoot_server_mul t icas t_address 

(01, OAAH, 0, OFFH, OFFH, OFFH) 

X ' The multicast address of the boot server. 

XMax_nodes (20) 

X ' The maximum number of nodes in the boot 
X' table (if used). 

XMax_5imultaneous_boots (10) 

X ' The maximum number of nodes that can be booted 
X ' at one time. 

XC 1 as s_code_i nf o C/USER/CC. INFO, 200H) 

X ' The class code information file is called 

X' /USER/CC.INF0. 

X' I USER/CC . I NF0 is at most 200H bytes. 

XDevi ce_i nf o_b 1 oc k (WD0, I W , NAMED) 

X ' The physical device IW0 is connected and 
X ' the file connection is cataloged as WD0 in the 
X' ROOT job directory. All files used by the boot 
X ' server are on this device. 

XNmf_cnf g ( 4 , 1 ) 

X ' The full capability of the NMF is configured 

X ' into the system. 
END 

The NMF can be left out of the COMM system by omitting the files NMFCFG.OBJ 
and NMF.LNK during the linking process. 
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CHAPTER 7 
ROM-BASED NMF 



7.1 Overview 



A primitive NMF can be burned into ROM for system start-up and reset. This ROM- 
based NMF or NMF ROM is primarily used for downloading. Since at system 
initialization the communication system is not present, the functions of the NMF 
that use the transport layer are not ROM-based. The NMF functions that use the 
service of only the data link layer are ROM-based. 



NMF ROM consists primarily of the boot consumer, which, in conjunction with the 
boot server, can download the operating system. Nodes are expected to have NMF 
ROM burnt into ROM's. After a hardware reset, the NMF ROM begins execution. 
It invokes the boot consumer which, in turn, downloads the operating system into 
local memory. After the operating system is loaded, NMF ROM is not used again. 
The similarity between NMF ROM and a bootstrap loader is evident; the only differ- 
ence is that the bootstrap loader downloads the system from the local mass storage 
controller, whereas NMF ROM downloads the system from the boot server. 



The NMF ROM-based functions fall into two categories: 

• Remote invocations - Upon receipt of a packet, the ROM-based NMF only 
responds if the packet has the NMF DLSAP. Furthermore, only the following 
commands are recognized: Echo, Forced_load, Dump. 

• Local invocations - The only user-initiated function recognized by the ROM- 
based NMF is the down-line loading facility. This facility uses a simple proctocol 
in conjunction with the boot server to receive data and store it in the appropriate 
memory locations. The ROM-based NMF can be configured to initiate a boot at 
system reset. 



The ROM-based NMF consists of two files, ROMA.OBJ and ROMB.OBJ. In 
addition, the user must include a User_code module that performs any functions 
required to be placed in ROM. For example, power-on diagnostics would be placed 
in the User_code module. To configure the ROM-based NMF, the NMF ROM object 
code, the user code, and a configuration file (CNFG.OBJ) are linked and located and 
the resulting file is burned into ROM. 



7.2 Boot consumer 



In order to force the NMF ROM to attempt a remote boot, include a call to the 
procedure Boot_consumer in the User_code module. Boot_consumer is a typed proce- 
dure included in the ROM-based NMF. It takes a class code as an input parameter 
and returns a status byte for the result of the operation. A call to this procedure 
initiates an attempt to contact the boot server with a downline load request with the 
given class code. The procedure returns a value of OK or NOTOK depending on 
whether the boot server responded to the request. 



7-1 



ROM-Based NMF iNA 960 



This procedure is defined below: 

Boo t.consumer : PROCEDURE < C 1 a s s_c o d e ) EXTERNAL BYTE; 
DECLARE Class_code WORD; 

/* Responses are TRUE - Ok response 

FALSE - No reponse from boot server */ 

END Boot_consumer; 



7.3 User_code 

User code such as power-on diagnostics can be included in the ROM-based NMF. 
To do this, create a User_code module in the format shown below. If the communi- 
cations CPU is an 80186, include code that initializes the chip-select lines. 

Use r_c ode: DO; 

/* For the 80186, initialize the chip-select lines ♦/ 

/« User code goes here */ 

DI SABLE ; 

CALL Init_controller; 

/♦This procedure initializes the communications 
controller and enables interrupts. Now, the 
NMF ROM responds to Echo, Dump, IEEE XID and 
Test commands, */ 

Status = Boot_consumer (Class_code); 

/* This section of code is reached only when the 

remoteboot is unsuccessful , * I 

IF Status <> THEN DO; 

/» No response from boot server. Take corrective 

action such as calling the boot server again. */ 
END ; 

END Use r_c ode; 

The file AUTBOT.P86 is included in the delivery diskette. The user should examine 
this file and use it as the user code module if it meets his requirements. 

AUTBOT.P86 is the file generated by the following source code: 

Autoboot: DO; 

Boo t_consumer : PROCEDURE ( C 1 a s s_c o d e ) EXTERNAL BYTE; 

DECLARE Clas s_code WORD ; 
END Boot_consumer; 

I ni t_cont rol ler : PROCEDURE EXTERNAL; 
END I n i t_c o n t r o 1 1 e r ; 

DECLARE Status WORD ; 

/• If the processor is an 8018G, then code to 

initialize the chip-select lines goes here. »/ 
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DI SABLE ; 

CALL I n i t_c o n t r o 1 1 e r ; 

DO WHILE (OFFH); 

Status = Boot_consumer (Class_code); 

/* If the boot process is successful, then program 
control never reaches here; hence, the infinite 
loop. • / 

END ; 

END Autoboot; 



7.4 Configuring the ROM-Based NMF 

The file CNFG.OBJ is linked with the rest of the ROM-based NMF to form a file 
that is located and burned into ROM. CNFG.OBJ is the object file generated from 
the configuration file CNFG.A86, described in this section. CNFG.A86 contains the 
macro calls used to configure the ROM-based NMF. 



7.4. 1 Boot_server_multicast_address 

This macro sets the multicast address of the boot server. The NMF uses this address 
to locate the boot server. This macro has the following form: 

XBoot_5erver_multica5t_addre55 (Multicast_addres5) 

where 

Multicast address is the multicast address of the boot server. 



7.4.2 Data_link_type 

This macro specifies the type of the data link layer. Such a macro is needed for future 
releases that support different data link types. Currently, the only valid value is 
IEEE802. This macro takes the following form: 

XDa t a_l i n k_t y pe (Dl_type) 

where 

DLtype is IEEE802. 



7.4.3 Host_id 

The Host_id macro sets up the host id of the Ethernet controller. There are two 
possibilities: 

• The 550a Ethernet controller cannot have its host id changed. In this case, the 
macro must still be invoked; however, a host id of should be used. 

• The 82586 Ethernet controller can have its host id changed using this macro. If 
the default host id of the 186/51 is desired, the host id should be set to a broad- 
cast address. 
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The Host_id macro has the following form: 
XHost_id (H_id) 



where 
H id 



is the host id. 



7.4.4 Board_type 

This macro specifies the type of programmable interrupt controller (PIC) used. iNA 
currently supports two PICs: the 8259a and the PIC in the 80130. This macro speci- 
fies the master PIC in the system. This macro has the following form: 

The macro has the following form: 

X B o a r d__t y p e (Type, W a k e_u p_p o r t , Reserved, 
S c p_o f f s e t , Scp_base) 



where 
Type 



Wake_up_port 

Reserved 
Scp_offset 

Scp_base 



is one of the following: 

186/51 -fortheiSBC 186/51. 
550A - for the iSBC 550A. 

is for the iSBC 186/51. Otherwise, it is the wake-up port 
of the iSBC 550A. 

must be set to 0. 

is for the iSBC 186/51. Otherwise, it is the offset value of 
the SCP address of the iSBC 550A. 

is for the iSBC 186/51. Otherwise, it is the base value of 
the SCP address of the iSBC 550A. 



7.4.5 Master_PIC 

This macro specifies the type of programmable interrupt controller (PIC) used. iNA 
currently supports two PICs: the 8259a and the PIC in the 80130. This macro speci- 
fies the master PIC in the system. This macro has the following form: 

XMaster_PIC (Type, Base_port, Increment, Buffered) 



where 
Type 



Base_port 
Increment 



Buffered 



is the type of programmable interrupt controller, 80130 or 
8259a. 

is the port address of the PIC. 

is a value used to specify the other ports of the PIC. These 
ports will be at I/O addresses having the following form: 

Base_port + (i * Increment) 

where i is a non-negative integer. Increment will usually have 
the value 1 or 2. 

has the following values: 

Y - if the PIC supports vectored (cascaded) interrupts. 

N - if the PIC does not support vectored interrupts. 
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7.4.6 Data_link_interrupt 

This macro is used to configure the type of data link interrupts used in the system. 
Although the form of the macro includes the specifications for either a master or a 
slave interrupt, the interrupt must be configured as a master. The macro has the 
following form: 

X D a t a_l i n k_i n t e r r u p t (Int type, Int_value, Int_level) 

where 

Int_type specifies the way the data link controller interrupts the CPU: 

- level mode interrupts 

1 - memory-mapped interrupts 

2 - I/O-mapped interrupts 

This value must be if the 186/51 is used. 

Int_value depends on the value of Int_type, as follows: 

Int_type = - Int_value must be 0. 

Int_type = 1 - Int_value is the upper 16 bits of the memory 
address for the interrupt. The lower 4 bits are 
taken to be 0. 

Int_type = 2 - Int_value is the port address. 

Int_level specifies the interrupt level according to the following code: 

bits 15-7 areO. 

bits 6-4 specify the master level (0-7) of the 

interrupt. 

bit 3 has the following values: 

- The interrupt has a slave level, bits 6-4 

specify the master level, and bits 2-0 
specify the slave level. 

1 - The interrupt has a master level, and bits 

6-4 specify the entire level number. 

bits 2-0 specify the slave level of the interrupt if bit 

3 isO. 



7.4.7 System_configuration_pointer 

This is the only optional configuration macro. It is used only with the iSBC 186/51. 
This macro specifies the size of the system data bus and the location of the interme- 
diate system configuration pointer (ISCP) of the 82586 controller. The format for 
this macro is as follows: 

XSystem_configuration_poiTiter (Sys_bu5, Iscp_low, Iscp_high) 

where 

Sys_bus is one of the following: 

- 8-bit system data bus 

1 - 1 6-bit system data bus 

Iscp_low specifies the lower 16 bits of the ISCP. 

Iscp_high specifies the higher 8 bits of the ISCP. 



7-5 



ROM-Based NMF iNA 960 



7.4.8 Sample Configuration 

The ROM-based NMF configuration file, CNFG.A86, contains macro calls that 
configure the NMF, data link, and board parameters. Following is an example of this 
configuration file: 

NAME NMF_RDM_CNFG 

$ I NCLUDE (:Fn:CNFG.A86) 

XMas ter_P IC (80130, OEOH, 2 , Y) 

XBoot_serve r_m ulticast_addre55 

(1, A A H , 0, OFFH, OFFH, OFFH) 
%Host_id (OFFH, OFFH, OFFH, OFFH, OFFH, OFFH) 
XDa t a_l i n k_t y p e (IEEE802) 
XBoard_type (ISBC 186/51, 0, 0, 0, 0) 
XDa t a_l i n k_i n t e r r u p t (0, 0, 38H) 

END 



7.5 Linking and Locating the ROM-Based NMF 

To prepare the ROM-based NMF for burning into EPROM's, follow this procedure: 

1. Copy the diskette containing the ROM-based NMF into the directory NMFROM 
on the iRMX 86 system Winchester. 

2. Write the user code. 

3. If you use the file AUTBOT.P86 and have the iSBC 186/51, include the code to 
initialize the 80186 chip select lines in the file AUTBOT.P86. 

4. Compile the user code with the PL/M-86 compiler controls COMPACT, ROM, 
and OPTIMIZED). 

5. Modify and assemble the configuration file CNFG.A86. 

6. The submit file ROM.CSD, which links and locates the ROM-based NMF, may 
need modification. If user code is included, the user code object file should replace 
AUTBOT.OBJ in the linker invocation. In addition, the BOOTSTRAP control 
may be included in the locator invocation. 

7. Link and locate the ROM-based NMF by typing the following: 

SUBMIT NMFROM/RQM . CSD ( L o c a t i o n_o f _d a t a , 
Locat ion_of_code) 

where 

Location_of_data is the address where the data is to be located. 
Location_of_code is the address where the code is to be located. 

The LINK86 warning message "Group Enlarged" is acceptable. LOC86 warning 
messages 38 and 65 are also acceptable. 

8. Burn the file ROM into the EPROMs. 
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CHAPTER 8 
iRMX ™ 86 SYSTEM GENERATION 



8.1 Overview 

To run on the iRMX 86 operating system, iNA 960 requires an environment that 
includes the iRMX 86 nucleus, an 8086 or 80186 CPU, an 82586-like Ethernet 
controller, and a dedicated timer. For example, iNA 960 can be configured to run on 
an iSBC 186/51 or an iSBC 86/330 with a 550FW conversion kit as the data link 
controller. In this configuration, the iNA 960 communications software runs as a 
first-level job on the iRMX 86 nucleus. 

The iNA 960 software must be configured according to the underlying hardware. 
For an iSBC 186/51 environment, iNA 960 has a set of default configuration files 
that can be used directly. However, for the iSBC 86/330 with the 550 firmware kit, 
and for any other hardware setups, the configuration files must be modified. 

In addition to configuring iNA 960 for the hardware, the data link layer, the trans- 
port layer, and network management must be configured. This procedure includes 
provisions for selecting several optional functions. These optional functions are the 
user data link, the transport normal virtual circuit services, the transport expedited 
services, the transport datagram services, the network management functions, and 
the bootstrap loader-server. 

This chapter describes the procedure for configuring the hardware and software. After 
configuring iNA 960, the COMM job can be used in the same manner as other first- 
level user's jobs. (See the iRMX 86 Configuration Guide for a description of the 
configuration steps). 

The end of the chapter contains a section describing the procedure for initializing the 
iAPX 186 microprocessor in iRMX 86 compatible mode. 



8.1.1 iNA 960 System Generation Procedure 

The iNA 960 software is configured and the communication system is generated by 
the following steps: 

1. Prepare the hardware environment. 

2. Load the iNA 960 software modules onto the development system. 

3. Configure iNA 960 by modifying the following configuration files: 
RMXCFG.A86 Configures the iNA 960 base system. 
BUFCFG.A86 Configures the iNA 960 buffer usage. 
DLCFG.A86 Configures the data link layer. 
NMLCFG.A86 Configures network management functions. 
TLCFG.A86 Configures the transport control layer. 

4. Select those optional functions required by the system. The optional functions 
are the user data link interface, the transport datagram services, the transport 
normal virtual circuit services, the transport expedited services, the network 
management functions, and the bootstrap loader-server. 

5. Link the configuration files with COMM.LNK and any other necessary 
iRMX 86 library files. Locate the resulting COMM job. 

6. Use ICU to configure the COMM job as one of the first-level user jobs. 



iRMX™ 86 System Generation iNA 960 



8. 1 .2 Preparing the Hardware 

The iNA 960 software modules include default configuration files. These files 
configure the software for an iSBC 186/51 hardware environment. In addition, the 
interrupts are assumed to be configured as follows: 

iAPX 186 Timer 1 OUT ** ► 80130 IR4 Input (E78-E43) 

82586 INT ** ► 80130 IR0 Input (E39-E47) 

For an 86/330 with 550FW environment or for any other hardware configuration, 
the configuration files need certain modifications. These changes are described in the 
following sections. 



8.1.3 Transferring the iNA 960 Files 

On an iRMX 86-based development system such as the 86/330, the iNA 960 software 
should be transferred to the development system Winchester disk. To do this, insert 
the iNA 960 Object - COMM diskette into disk drive and type the following: 

SUBMIT :FDO:CSD/INSTALL.CSD (: logicaLdevice : ) 

where 

logicaLdevice is the logical device name of the destination file system. It is 

best to use the system drive :SD: for the logical device name. 

The submit file then creates the directory :logical_device:COMM and copies the 
iNA 960 Communication system directories and files to the COMM directory. If a 
directory named COMM already exists on the destination file system, either rename 
it or change the name of the target directory in the submit file. 



WARNING 



The default configuration and submit files described in this chapter assume 
that the iNA 960 Communication system resides in :SD:COMM. If the 
system is installed on a different directory or if you are an ISIS user, the 
configuration and submit files must be changed to reflect the actual locations 
of the files they reference. For the configuration files this means the 
INCLUDE statements must be changed. For submit files, the pathname of 
each file in the link list must be changed. 



8.2 Configuration 

Configuring the iNA 960 software consists of configuring the base hardware and the 
buffer usage, and also configuring the operating parameters of the data link layer, 
transport layer, and the NMF. Default configuration files are included; they may be 
used directly or may be edited to reflect the desired configuration. Also included is a 
submit file that assembles, links, and locates the communication system. 



8.2.1 Configuring the Base System 

For internal timing, the iNA 960 software requires a hardware timer such as the 
iAPX 186 on-chip timer, an 8253, or something compatible. The default configura- 
tion file RMXCFG.A86 configures the system for the iAPX 186 on-chip timer. If 
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the 8253 is used or if timer parameters other than the default are needed, a different 
hardware timer configuration file must be created. This file consists of a single call 
of the following macro: 

XCOMM_TIMER (Type, Base_port, Timer, Level, Rate) 

where 

Type is the type of hardware timer used: 8253 or 80186. 

Base_port is the port address of the programmable interrupt timer. This 

address depends on the timer, as follows: 

80186 - The 80186 control block base address (0FF00H 
on reset). 

8253 - The port address of timer 0. 

Timer is the timer number (0-2) of the timer used by iNA 960. 

Level is an encoded value for the interrupt level of the interrupt 

controller to which the timer is connected. This value takes 
the following form: 

x8H - For master interrupt levels M0-M7 (where x can 
be from to 7). 

yzH - For slave interrupt levels 00-77 (where y and z 
can be from to 7) 

Rate is the frequency in KHz of the input clock to the selected 

timer. This value must be between 10 and 2500 (10 KHz-2.5 
MHz). 

For the iSBC 186/51 user the default configuration file RMXCFG.A86 provides 
proper timer configuration. This file has the following form: 

NAME CDNF . A86 

$ I N C L U D E (:SD:COMM/CONFIG/RMXCFG.MAC> 

XC0MM_T I MER(80 1 86 , 0FF00H, 1, 48H, 1500) 

END 

Here RMXCFG.MAC contains the definitions of the macros used for configuring 
the system. 



8.2.2 Configuring the Buffer Usage 

The iNA 960 software allows the user to select the number of buffers used by the 
internal transmitter and receiver. Thus, the software can be configured to make 
optimum use of memory. The following entities are available for configuration: 

RXBD receiver buffer descriptor - Each RXBD takes a 142-byte 

block of memory, including 1 28 bytes for the buffer. 

TXBD transmitter buffer descriptor - Each TXBD takes a 1520 byte 

block of memory, including 1 500 bytes for the buffer. 

RPD receive packet descriptor - Each receive packet, regardless of 

length, uses one RPD. Each RPD takes a 36-byte block of 
memory. 

ICB internal command block - The ICBs are resources internal 

to iNA 960. They are used for passing requests internal to 
the iNA 960 software. Each ICB takes 36 bytes of memory. 
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The following macro is used to allocate memory for the above entities: 
XCOMM_BUFF (N_rxbd, N_txbd, N_rpd, N_icb) 

where 

N_rxbd is the number of RXBDs. The minimum number of RXBDs 

required for receiving a full length IEEE 802 packet is 12. 
However, the more RXBDs specified, the more back-to-back 
receiving can be achieved (providing enough RPDs are 
specified). 

N_txbd is the number of TXBDs. Each TXBD can send a full length 

IEEE 802 packet. Setting N_txbd to 2 provides full transmit 
throughput. A larger value does not increase the transmit 
throughput. 

N_rpd is the number of RPDs. N_rpd, together with N_rxbd, deter- 

mines the number of back-to-back receiving of packets. 

N_icb is the number of ICBs. For the current release of the 

iNA 960 software, this number must equal N_txbd. 

For iSBC 186/51 users the default configuration file BUFCFG.A86 provides adequate 
initialization of the buffers. This file has the following form: 

NAME BUFFCDNF 

$ I N C L U D E (:SD:COMM/CONFIG/BUFCFG.MAC) 

XCOMM_BUFF (144, 2 , 20, 2) 

END 

Here,BUFCFG.MACcontainsthemacrodefinitionofCOMM_BUFF.COMM_BUFF 
is the buffer configuration macro described above. 

The allocation of the number of internal receive buffers via the RXBD and RPD 
parameters has a major impact on transport layer data throughput performance. The 
critical dependency is the number of 1 500-byte transport packets (TPDUs) that can 
be buffered at one time without running out of internal receiver buffer resources. 

For example, for the default 186/51 configuration (144 128-byte BDs and 20 RPDs), 
a maximum of twelve 1 500-byte TPDUs can be buffered at one time. For optimum 
performance, the number of TPDUs specified here determines the proper maximum 
window size parameters that must be used when configuring the transport layer. 



8.2.3 Configuring the Data Link Layer 

The data link software must be configured for the particular hardware environment. 
For instance, all of the following are specified during data link configuration: 

• Number of data links 

• Protocol, controller class, and controller subclass 

• Interrupt parameters 

• Addressing information 

• Channel transmission rate 

• Maximum number of multicast addresses 

• The configuration array used to initialize the 82586 
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Note that some operating parameters are fixed, such as number of data links, proto- 
col, and controller class. These parameters are included for future expansion. 

The default configuration file DLCFG.A86 has the following form: 

NAME DLCFG 

$ I N C L U D E (:SD:COMM/CONFIG/DLCFG.MAC) 

XDl_c t r 1 ( 1 ) 

XDl_i n t ( 08H) 

XD1_5 ignal ( 2 , 0C8H) 

XDl_scp_addr (6H , OFFFFH) 

% D l_i scp_addr ( , OFFH) 

XDl_host_id (6, OFOH, 0F2H, 0F4H, 0F6H, 0F8H, OFAH) 

KDl_in t ernal 

END 

See Chapter 3 for a description of the data link definition macros and their associated 
parameters. 



8.2.4 Configuring the Transport Control Layer 

The transport control layer has a large number of configuration parameters that 
customize the transport layer to a particular implementation. These parameters can 
be split into the following parameter groups: 

• Transport address limits 

• Network layer interface parameters 

• Transport data base parameters 

• Client request default parameters 

• Internal negotiation default parameters 

• Retransmission timer parameters 

• Flow control parameters 

Chapter 5 contains descriptions of all of these parameter groups and shows the format 
for the transport control layer configuration file. Following is the default transport 
configuration file, TLCFG.A86: 



NAME TLCFG 

$ I N C L U D E (:SD:COMM/CONFIG/TLCFG.MAC) 

X T r a n 5 p o r t_a d d r e 5 s_l i m i t 5 (12, 2, 2) 

XNetwork_layer_interface (1) 

Uonnect ion_l imi t s (21, 2) 

XDatagram_structure5 (9, 0, 0) 

XInternal_request_block5 (5, 2,3, 2) 

XC 1 i en t_r eques t_def au 1 t a (1, 1800H, 8242H) 

X I n t e r ti a l_n e g o t_o p t i o n 5 (OBH, 3, 7) 

XRe t ran_t i m e r (10 0, 1000) 

XC 1 OS i ng_abor t (80H) 

X I na c t i v i t y_t i me r (300000, 8) 

XWindow_s ize (0FH, 0FH, 1) 

X Ope n_w i n d o w_t i me r (10000, 8) 

END 
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8.2.5 Configuring the Network Management Facility 

The user has many options when configuring network management. In particular, 
configuration may include a boot server that can down-load remote systems. 
Chapter 6 describes the macros, parameters, and options available to the user when 
creating the network management configuration file. 

The completed network management configuration file resembles the following default 
configuration file, NMLCFG.A86: 



NAME NML_CNFG_MACROS 

$ INCLUDE (:SD:COMM/CONFIG/NMLCFG.MAC) 

XBOOT_SERVER_MULT I CAST_ADDRESS 

(1, AAH , 0, OFFH, OFFH, OFFH) 
XNML_CNFG (3, 1) 

MAX_N0DES (10) 

MAX_S I MULTANE0US_B00TS (10) 

CLASS_C0DE_I NFO (:SD:C0MM/C0NFIG/CC_INF0, 

D E V_I NF0_BL0CK (WDO, IWO, NAMED) 
END 



200 ) 



Note that in this default NMF configuration, the boot server is not selected. 



8.3 Selecting Optional Functions 

Before linking and locating the configuration files, the optional functions to be included 
in the COMM system must be selected. Table 8-1 lists the files that provide these 
options. 

The default submit file COMM.CSD (see next section) includes TL.LNK and 
TLVC.LNK. To include any other configuration files, edit COMM.CSD to add the 
desired files to the link list. 



8.3.1 Data Link Options 

At link time, the COMM job can be configured to include user data link services. To 
do this, include the file LNK/EDL.LNK in the COMM.CSD submit file link list. 





Table 8-1 


. Optional Modules 


Filename 


Code Size 


Option 


LNK/EDL.LNK 


4K 


User data link interface. 


LNK/TL.LNK 


3.3K 


Transport layer core. 


LNK/TLDG.LNK 


2.9K 


Transport datagram functions. 


LNK/TLVC.LNK 


15.4K 


Transport normal virtual circuit service. 


LNK/TLEX.LNK 


1.9K 


Transport virtual circuit expedited services. 


LNK/BTSRV.LNK 


4.7K 


Bootstrap loader server. 


LNK/NMF.LNK 


6K 


Network management functions. Subsets of the 
NMF can be configured. 
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NOTE 

Always include the data link configuration file, DLCFG.OBJ, in the 
COMM.CSD submit file whether or not the user data link is required. 



8.3.2 Transport Layer Options 

At link time, the COMM job can be configured using several options for the trans- 
port layer. To configure the transport options, select from the following modules: 

LNK/TL.LNK - Transport layer core 

LNK/TLVC.LNK - Transport normal virtual circuit services 

LNK/TLEX.LNK - Transport virtual circuit expedited services 

LNK/TLDG.LNK - Transport datagram services 

CONFIG/TLCFG.OBJ - Transport configuration file 

The user has the following options: 

1. No transport layer services are configured into the COMM job. For example, 
the COMM job may support only external data link services. In this configura- 
tion, do not link in any of the above modules. 

2. Only the normal virtual circuit transport service is configured into the COMM 
job. This is the default system provided with the delivery diskette. In this config- 
uration, link in the modules TL.LNK, TLVC.LNK, and TLCFG.OBJ. 

3. Both the normal and expedited virtual circuit services are configured into the 
COMM job. For this configuration, link in the modules TL.LNK, TLVC.LNK, 
TLEX.LNK, and TLCFG.OBJ. 

4. Only the transport datagram services, without any virtual circuit services, are 
configured into the COMM job. In this configuration, link in the modules 
TL.LNK, TLDG.LNK, and TLCFG.OBJ. 

5. All transport services, including normal, expedited, and datagram services, are 
configured into the COMM job. For this configuration, link in all of the above 
transport modules. 



8.3.3 NMF Options 

The COMM job can be configured to include a subset of the network management 
services and to include the boot server functions. Following are the NMF modules: 

LNK/NMF.LNK - NMF services 

LNK/BTSRV.LNK - Boot server services 

CONFIG/NMFCFG.OBJ - NMF configuration file 

The user has the following options: 

1. No NMF services are configured into the COMM job. In this configuration, do 
not link in any of the above modules. 

2. Only the NMF services are configured into the COMM system. For this config- 
uration, link in the modules NMF.LNK and NMFCFG.OBJ. 

3. In addition to the NMF services, the boot server is configured into the COMM 
job. For this configuration, link in all of the above modules. 
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8.4 Linking and Locating the Configuration Files 

Once the configuration files are customized, the corresponding object files are linked 
with the COMM job and with necessary library files. The result is then located to 
match the user's implementation. If any of the optional functions are used, first add 
the necessary files to the link list in COMM.CSD, then perform the following: 

>SUBMIT :SD:C0MM/CSD/C0MM.CSD istart_address) 



where 

start_address 



is the starting address of the COMM job. 



COMM.CSD assembles the configuration files, links the selected modules, and locates 
the COMM job at the specified address. The default COMM.CSD takes the follow- 
ing form: 



ASM8G 



SD : CQMM/CONF I G/RMXCFG . A86 , 4 

SD : C0MM/C0NF I G/BUFCFG . A86 , 4 

SD : COMM/CONF I G/DLCFG . A86 , 4 

SD : COMM/CONF IG/TLCFG . A86 , 4 

SD : COMM/CDNF I G/NMLCFG . A86 , & 



L I NK86 



SD 
SD 
SD 
SD 
SD 
SD 
SD 
SD 
SD 



COMM/LNK/CDMM . LNK , & 
COMM/LNK/TL . LNK , & 
COMM/LNK/TLVC.LNK, 4 
COMM/CONF I G/RMXCFG . OBJ 
COMM/CONF IG/BUFCGF . OBJ 
COMM/CONF IG/DLCFG . OBJ , 
COMM/CONF IG/TLCFG. OBJ, 



COMM/LNK/ A I MRMX .LIB 4 
COMM/LNK/COMM .LIB 4 
TO : SD : COMM/ LNK/COMMCF . LNK 4 
NOCM NOLI NOMAP NOSB 4 
NOPUBLICS EXCEPT (COMMENTRY 



CQERRORCODE) 



ENTRYPTS , DATA , STACK) ) 4 



L0C86 :SD:COMM/LNK/COMMCF.LNK 4 

TO : SD : COMM/LNK/COMM 4 

ORDER (CLASSES(CODE. 

SEGS I ZE ( STACK ( ) ) 4 

ADDRESSES (CLASSES (CODE (XO))) 4 

NOINITCODE, NOLINES, NOCOMMENTS, NOSYMBOLS, 4 

OB JECTCONTROLS (NOLINES, NOCOMMENTS, NOPUBLICS 

NOSYMBOLS) 



See the MCS-86 Utilities User's Guide for descriptions of the LINK86 and LOC86 
commands and the associated command options. 



8.5 Configuring the COMM Job into iRMX™ 86 

After linking and locating the COMM job, the iRMX 86 ICU can be used to include 
the COMM job into the iRMX 86 system, just as with the first-level user's job. 
Following are the suggested parameters: 



User Job 

(ODS) Object Directory 

(PMI) Pool Minimum [2 OH 



Size [0 - OFFOH] 
- OFFFFH] 



0003H 
0600H 
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(PMA) Pool Maximum [2 H - OFFFFH] FFFFH 

(MOB) Maximum Objects [1 - OFFFFH] FFFFH 

(MTK) Maximum Tasks [1 - OFFFH] FFFFH 

(MPR) Maximum Priority [0 - F F H] 0000H 

(AEH) Address of Exception Handler [C S : IP] 0000H:0000H 

(EM) Exception Mode [Never/Prog/Environ/All] Never 

(PV) Parameter Validation [Yes/No] No 

(TP) Task Priority [0 - F F H] 0130 

(TSfi) Task Start Address [CS: IP] start_address 

(DSB) Data Segment Base [0 - OFFFFH] 0000H 

(SSA) Stack Segment Address [SS:SP] 0000H:0000H 

(SS) Stack Size [0 - OFFFFH] 0400H 

(NDX) Numeric Processor Extension Used [Yes/No] No 

where 

start_address is the address of the label "CommEntry" from the locate map 

(COMM.MP2). 

Refer to the iRMX 86 Configuration Guide for a description of the procedures to 
configure the first-level user job. 

NOTE 

User tasks that use the COMM interfaces must have lower priorities (higher 
numeric values) than the init task priority parameter of the JOB macro. 



8.6 COMM Job Requirements 

In order to run the COMM job, the Nucleus must be configured with the following 
system calls used by the COMM job: 

RQ$CATAL0G$0BJECT 
RQSCREATE $C0MP0S I TE 
RQ$CREATE$EXTENSION 
RQ$CREATE$MAILB0X 
R Q $ C R E A T E $ S E G M E N T 
R Q $ C R E A T E $ S E M A P H R E 
RQ$CREATE$TASK 
RQ$DELETE $C0MP0S I TE 
R Q $ D E L E T E $ S E G M E N T 
RQ$END$ I N I TTASK 
RQ$ENTER$ I NTERRUPT 
RQ$EXIT$INTERRUPT 
RQ$GET$TASK$T0KENS 
RQ$RECEIVE$MESSAGE 
RQIRECE I-VE $UN I TS 
RQ$RESUME$TASK 
RQ$SEND$MESSAGE 
RQ$SEND$UNITS 
RQ$SET$ INTERRUPT 
RQ$SET$0S$EXTENSI0N 
RQ$S I GNAL$ INTERRUPT 
RQ$WAIT$INTERRUPT 
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If the boot server is configured into the COMM job, both the Nucleus and BIOS 
must be configured into the system. In addition to the above system calls, the follow- 
ing system calls must be included in the Nucleus configuration: 

RQIDELETE$MA I LBOX 
RQIGETIPR IOR ITY 
RQ$GET$TYPE 
RQ$LOOKUP$QBJECT 

If the boot server is configured into the COMM job, the following system calls must 
be included in the BIOS configuration: 

RQ$A$ ATTACH$F I LE 

RQ$A$CL0SE 

RQ$A$DELETE$CONNECTI ON 

RQ$A$GET$CONNECTION$STATUS 

RQ$ A$GET$F I LEISTATUS 

RQ$ A$0PEN 

RQ$A$PHYSICAL$ATTACH$DEVICE 

RQ$A$READ 

RQ$A$SEEK 

RQ$CREATE$USER 

RQ$SET$DEFAULT$PREFIX 

RQ$SET$DEFAULT$USER 



8.7 Initializing the iAPX 186 

The iNA 960 includes code to initialize the iSBC 186/51 in iRMX 86 compatible 
mode. This initialization is required only for iRMX 86 release 5. iRMX 86 release 6 
and subsequent releases perform their own initialization. 

If the SDM86 is used, the initialization code is not needed. Following is a description 
of the initialization procedure. See the iAPX 186 Data Sheet for a description of the 
registers used in the initialization code. 

The initialization code performs the following actions: 

• Sets the relocation register to 0FF00H. This, in particular, sets bit 14, selecting 
the iRMX 86 compatible mode. The internal interrupt controller then operates 
as a slave. 

• Loads the memory and peripheral chip-select registers UMCS, LMCS, MPCS, 
MMCS, and PACS. This loading establishes the sizes and address boundaries of 
the chip-selectable memory and peripheral blocks. In addition, this loading selects 
the WAIT state timing and READY generation logic for each of the chip-select 
lines. 

• Branches to the specified entry address (for example, the entry address of the 
ROOT job.) 

iAPX 186 initialization is activated by a call of the following macro: 

% I N I T_1 8 6_C F (UMCS, LMCS, MPCS, MMCS, PACS, 
B r a n c h_o f f 5 e t , Branch_base) 
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where 

UMCS 

LMCS 

MPCS 

MMCS 

PACS 

Branch_offset 
Branch base 



is a word that initializes the UMCS (upper memory chip- 
select) register. To leave the register alone, specify 0. 

is a word that initializes the LMCS (lower memory chip- 
select) register. To leave the register alone, specify 0. 

is a word that initializes the MPCS register. This register 
selects the mid-range memory block size and controls the 
operation of the peripheral chip-select. To leave this register 
alone, specify 0. 

is a word that initializes the MMCS register. This register 
sets the base address of the mid-range memory block. To leave 
this register alone, specify 0. 

is a word that initializes the PACS register. This register sets 
the base address of the peripheral chip-select block. To leave 
this register alone, specify 0. 

is a word that specifies the offset of the address to be branched 
to after initialization. 

is a word that specifies the base of the address to be branched 
to after initialization. 



The macro INIT_186 sets the relocation register, loads the memory and peripheral 
chip-select registers with the parameter values, then vectors to the location specified 
by the Branch parameters. Normally, this address is the entry address of the ROOT 
job. However, it can also be the entry address for a user module. This module can be 
used, for example, to perform a diagnostics function or to run an initialization routine 
specific to the user's system. 

NOTE 

Only a specific set of values for the chip-select registers is valid. See the 
iAPX 186 Data Sheet for information on the bit fields of these registers. 

The iAPX 186 initialization routine consists of a single call of the INIT_186_CF 
macro. The iNA 960 software package includes a default iAPX 186 initialization 
file, IN186.A86. This file takes the following form: 

NAME INITIAL I Z E_1 86 

$ I N C L U D E (:SD:C0MM/INIT/IN186.MAC) 

X I N I T_1 8 6_C F (0, 0, 80BBH, 0, 003H, Offset, Base) 

END 

To modify IN186.A86, assemble it and generate the object code file, IN 186. OBJ. 
The initialization code is then linked and located by typing: 

>SUBMIT :SD:COMM/INIT/INIT.CSD ( start_address) 

Here, start_address is the address where the initialization code is to be located. Notice 
that INIT.CSD has a BOOTSTRAP LOC86 control. Here, a long jump to 
start_address is placed at 0FFFF0H when the module is loaded. 
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CHAPTER 9 
COMPONENT SUPPORT INTERFACE 



9.1 Overview 



The iNA 960 communications software can run under iRMX 86 as described in the 
previous chapter. In addition, iNA 960 can run as a standalone package. When 
operating as a standalone system, iNA uses the component support interface as 
detailed in this chapter. 

iNA runs independently of the host system, on a processor that is different from the 
host processor. The host passes commands to iNA by formatting request blocks and 
delivering them to iNA to execute. Following execution, iNA passes the request block 
back to the host. 

iNA is a hardware-independent software package. The hardware-dependent features 
are contained in a separate and configurable hardware-dependent module (HDM). 
iNA is also independent of the mechanism that is used to pass request blocks to and 
from the iNA software. The user has three choices for this message delivery mecha- 
nism (MDM): the MULTIBUS interprocessor protocol (MIP), the base control block 
(BCB) interface, and the user-supplied interface. For the MIP and the BCB, the 
user needs to write only some initialization routines. The user-supplied interface must 
be written entirely by the user. 

This chapter describes the three types of message delivery mechanisms. In addition, 
the hardware environment required to run the component support interface is detailed, 
including the steps needed to configure the hardware-dependent module. The chapter 
concludes with a description of the procedure for generating the COMM system from 
the component modules. 



9.2 Model of Operation 

Figure 9-1 illustrates the component support interface model of operation. The 
component support interface consists of the following modules: 

MDM - The message delivery mechanism running on the host processor. 
iMDM - The message delivery mechanism running on the iNA processor. 
HDM - The hardware-dependent module. 

Commands are passed from user tasks to iNA in the form of request blocks, via the 
two message-delivery mechanisms. Each command is executed by iNA, the request 
block is modified to reflect the result of the execution, and then the request block is 
dispatched back to the user task. The following is the sequence of events: 

1 . The host formats a request block in system memory. 

2. The host requests the MDM running on the host system to deliver the request 
block to the MDM running on the iNA processor. The host must not modify the 
request block after this step. 
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Figure 9-1 . The Component Support Interface 
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3. The MDM on the host processor accepts the request block. It uses the return 
entity field of the request block to store information about the source of the request 
block. This is used to identify the source task when returning the request block 
to the same task, after it has been processed by iNA. 

4. The MDM on the host generates a channel attention to interrupt the MDM 
running on the iNA processor. 

5. The channel attention interrupt service routine on the iNA processor services the 
interrupt. Here, the MDM on the host processor and the MDM on the iNA 
processor communicate following a predefined protocol. 

6. The MDM on the iNA processor accepts the request block, if it has the resources 
to handle it. 

7. The MDM on the iNA processor delivers the request block to iNA to process. In 
order to access the request block and the buffers specified in them, iNA calls a 
set of address conversion routines. 

8. After processing the request block, it is sent back to the original user task in a 
similar fashion. 



9.3 Hardware Environment 

Figure 9-2 shows the hardware environment used by the iNA 960 communication 
system. The 80186 CPU may be replaced by an 8086 CPU, an 8253 PIT and an 
8259 Programmable Interrupt Controller (PIC). The 82586 Ethernet controller may 
be replaced by a 550 FW board set. The system bus does not need to be a MULTI- 
BUS, as user-written subroutines account for variations in buses and hardware. 
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Figure 9-2 . iNA 960 Hardware Environment 
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9.4 iNA 960 Address Space 

It may not be possible for the iNA processor to access all of system memory at the 
same time. Different boards have different address spaces. For example, a hypothet- 
ical iNA processor may be able to access 256 Kbytes of system memory at any time, 
whereas system memory can be 1 Mbyte for a 8086-based system, and 16 Mbytes in 
a 80286-based system. 

Request blocks and the buffers specified in them are built by the host in system 
memory. Due to the different addressing capabilities of the various processors, it may 
not be possible for iNA to have access to all request blocks and associated buffers at 
the same time. In any given hardware configuration, there are two possibilities: 

• All request blocks and buffers specified in them are accessible by iNA at all 
times. 

• Request blocks and buffers specified in them are not always accessible by iNA. 



9.4. 1 Restricted Addressing 

Restricted addressing is the case where all request blocks and buffers are accessible 
to the iNA processor at all times. Special routines to manipulate the address space 
.of the iNA processor are not needed. For example, if the iNA processor can access 
256 Kbytes of system memory, then all request blocks and the buffers specified in 
them must reside in this 256-Kbyte block of memory. 
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9.4.2 Unrestricted Addressing 

In the case of unrestricted addressing, request blocks and buffers are scattered all 
over system memory. The iNA processor must, however, have access to all request 
blocks passed to the iNA software. Therefore, the MDM on the iNA processor first 
copies the request block to local memory (called the onboard request block). The 
MDM then delivers the onboard request block to iNA to process. After the request 
block has been processed, the MDM copies the onboard request block back to the 
user's request block. 

The iNA MDM maintains a pool of onboard request block buffers. The size and 
number of these buffers is set during configuration. Whenever a request block is to 
be delivered to iNA, a buffer from the onboard request block buffer pool is obtained 
and a copy of the request block is made. 

Note that buffers are not copied to local memory. iNA accesses buffers by calling a 
user-supplied routine (see Section 9.9) that adjusts the address window of the iNA 
processor to include the desired buffer. 

The following overhead is associated with the unrestricted addressing of request blocks 
and buffers: 

• A pool of onboard request block buffers must be kept and maintained. 

• Two sets of copies are performed for each request block delivered to iNA. 

• The address space of the iNA processor is continuously adjusted. 

Although the overhead due to the last point is minimal, the other points require a 
substantial amount of memory, and considerable processing time. These overheads 
are unavoidable. 



9.5 Message Delivery Mechanism 

The message delivery mechanism consists of two tasks running on the host and iNA 
processors as shown in Figure 9-1. The MDM running on the host is part of the host 
software and must be written by the user. The MDM running on the iNA processor 
can be one of two MDMs packaged with the system, or it can also be written by the 
user. Following are the three types of message delivery mechanisms: 

1. MULTIBUS interprocessor protocol (MIP) is a set of mechanisms and protocols 
that provide reliable and efficient exchange of data among tasks executing on 
various single board computers connected to a common MULTIBUS system bus. 
MIP solves the problems inherent in a multiprocessor system: 

Tasks can run on several different processors. 

Tasks can run on several different operating systems. 

Boards can use different signaling techniques. 

Boards can have different memory spaces. 

Boards can use different addressing schemes for the same shared memory. 

Tasks can share areas of memory without interfering with one another. 

Base control block (BCB) interface is used in systems that have a single host 
processor utilizing iNA. It is simpler to use than MIP. However, it is not as 
efficient. 

User-supplied interface can be used in systems where a user written interface is 
desired. 
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9.6 MIP Interface 

One of the message delivery mechanisms available to iNA is the MULTIBUS Inter- 
processor Protocol (MIP). The MIP facility included in the iNA package is an imple- 
metation of the MIP specification. Readers interested in the full specification of this 
protocol are referred to Appendix E. 

The MIP facility isolates user tasks from the complexities of communicating across 
the MULTIBUS system bus, and is recommended for MULTIBUS systems that have 
multiple host processors. 

MIP facilities support communication among tasks that are executing on different 
processor boards that are attached to a common MULTIBUS system bus. Each 
processor board in a MIP system runs a MIP facility. Each MIP facility may be a 
different implementation of MIP, but adherence to the specification ensures compat- 
ibility among them. 

The term device is used for each processor board in a MIP system. Each device has 
a device-id, a number between and the number of devices in the system (less 1 ). 
Figure 9-3 shows an example of a MIP system with a host device and the iNA 960 
processor board. 

Any two tasks can communicate with each other by passing data in an area of memory 
that is accessible by both of the devices on which the tasks execute. A contiguous 
block of memory through which data is passed under control of MIP facilities is 
called a buffer. The content of buffers is not interpreted by MIP facilities. 



<■ 



r 



r 



DEVICE 1: THE HOST DEVICE 



USER 
TASK A 



PORT1 



L__ 



MIP FACILITY 




DEVICE 0: iNA 960 DEVICE 



_ J 



L 



MIP FACILITY 



~l 



J 



> 



Figure 9-3 . MIP Facility with iNA 960 
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Communications are delivered to tasks at ports. A port is a logical delivery mecha- 
nism that enables delivery in first-in, first-out (FIFO) order. The ports at a given 
device are identified by a port-id, a number between and the number of ports 
(less 1) at the device. To provide system-wide addressability, a port is also identified 
by a socket, a pair of items in the form (d,p) where d is the device-id and p is the 
port-id. Thus, in the example shown in Figure 9-3, iNA resides on device and receives 
communications at port 16, that is, socket (00, 16). Similarly, TASK A and TASK 
B are active at sockets (1,1) and (1,0) respectively. 



9.6.1 MIP Initialization Routine 

The MIP user must write the initialization code and link it with the rest of the COMM 
software. This initialization code must do the following: 

• It must have a variable called This_device_loc, which is a POINTER that is 
declared PUBLIC and DATA. 

• The memory location addressed by This_device_loc must be initialized with a 
BYTE value specifying the device id of the iNA processor. It is recommended 
that the iNA processor be assigned a device id of 0. 

• It must have a variable called MIP_device_info_loc, which is a POINTER that 
is declared PUBLIC and DATA. 

• The memory area addressed by MIP_device_info_loc must be initialized with the 
following: 



DECLARE M I P_devi ce_i nf o BASED M I P_d e v i c e_i n f o_l o c 
STRUCTURE ( 

Devi ce_i d BYTE , 

Status BYTE , 

RQD_in DWORD, 

RQD_out DWORD, 

Reserved (4) BYTE ) ; 



where 

Device_id i s the device id of the host processor. 

Status mus t be set to 0FFH. 

RQD_in is the 32-bit absolute address of the request queue 

descriptor to the iNA processor. 

RQD_out is the 32-bit absolute address of the request queue 

descriptor from the iNA processor. 

It must initialize both the incoming and outgoing MIP queues. 

It must perform any special hardware initialization required. This may include 
loading iNA onto the RAM of the iNA processor, if iNA is RAM-based. 

It must follow the PL/M 86 COMPACT model with the ROM option in effect. 

After all of the above, it should jump to the routine Begin_aim. When it does 
this jump, at least 20 bytes of stack space must be available. 
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9.6.2 Return_entity Field of a Request Block 

The Return_entity field of a request block is 4 bytes long. When sending a request 
block to iNA, the Return_entity field must be filled by the user. For the MIP message 
delivery mechanism, the Return_entity field has the following interpretation: 

DECLARE Re t urn_en t i ty STRUCTURE ( 
Por t_i d BYTE , 

Devi ce_i d BYTE , 
Reserved (2) BYTE ); 



where 



Port_id is the port where the request block should be returned after 

it is processed. 

Device_id is the device id of the host processor. This value must be the 

same as MIP_device_info.Device_id. 

Reserved is set to 0. 



9.6.3 POINTER Fields of a Request Block 

All addresses specified in request blocks must be 32-bit absolute addresses. The 
addresses present in the request queue should also be 32-bit absolute addresses, because 
the iNA 960 MIP can communicate with just one device. While communicating with 
this sole device, it assumes an interdevice segment base of 0. 



9.6.4 User-Written Routines 

In addition to writing the initialization routine, the user has to write the following 
routines. These routines are described in Section 9.9. 

Sys_to_loc_addr 

Loc_to_sys_addr 

Save_address_space 

Restore_address_space 

Gen int 



9.7 BCB Interface 

With the base control block interface, commands are given to iNA by placing the 
address of the request block in a fixed location and then generating a channel atten- 
tion to the iNA processor. The BCB interface then delivers the request block to iNA 
to process. Once the request block is processed, the BCB interface returns the request 
block to the host in a similar fashion. 



9.7.1 Base Control Block 

The memory location used to store the address of the request block is part of a contig- 
uous block of memory called the base control block. In addition to the request block 
address, the base control block contains fields used by the BCB interface to store 
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commands and responses used in the implementation of a request block passing 
protocol. The base control block is 96 bits long and has a format defined by the 
following PL/M-86 structure: 



DECLARE BCB_s t rue ture STRUCTURE ( 
Command 

Command_block_resul t 
Command_b 1 oc k_addre 5 5 
Re5ponse_block_addre55 



(16) BITS, 

(16) BITS , 

(32) BITS , 

(32) BITS ) 



Here, Command and Command_block_address are written to by the host, and read 
from by the BCB interface. These fields are used to issue a command to (or to 
acknowledge a channel attention from) the BCB interface, as described in the next 
section. If the command field contains a Start directive, the 32-bit absolute address 
of the request block to be sent to iNA, must be loaded into the Command_block- 
_address field before issuing the channel attention. 

Similarly, Command_block_result and Response_block_address are written to by the 
BCB interface, and read by the host. Command_block_result is used by the BCB 
interface to indicate the status of an issued command. The Response_block_address 
field is used to pass the 32-bit absolute address of a request block after it has been 
returned from iNA. 

Operation of the two sides of the message delivery mechanism is asynchronous. In 
particular, the BCB interface will accept new request blocks before it has completed 
processing old ones, up to a configurable limit. The order that request blocks are 
returned can be different from the order that they were issued. In addition, if the 
BCB interface has issued a channel attention to the host, no more request blocks are 
returned until the host has acknowledged the interrupt. 



9.7.2 Command Field 

Whenever the host generates a channel attention to the BCB interface, the reason for 
generating the interrupt is specified in the Command field of the base control block. 
This field is 1 6 bits wide and has the following interpretation: 



Bit 


Mnem 


Description 


15 


Ack 


This bit is set by the host to acknowledge a channel attention issued 
by the BCB interface. 


14 


Reset 


This bit is set by the host to reset iNA. The iNA processor disables 
interrupts and jumps to location FFFF:0. 


13 


Start 


This bit is set by the host to deliver a request block to the BCB inter- 
face. The 32-bit absolute address of the request block must be present 
in the Command_block_address field. 


12-0 


- 


Unused. Must be set to 0. 



The BCB interface interprets the bits in the following manner. If the Ack bit is set, 
the BCB interface clears the channel attention it had generated. If it had not gener- 
ated a channel attention, it ignores this bit. The BCB interface then examines the 
rest of the bits. Not more than one of these bits should be set at any time. If more 
than one of these bits is set, the BCB interface accepts the command corresponding 
to the highest bit set (order of priority is Reset, Start). In particular, an Ack can be 
combined with a Reset or a Start. 
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9.7.3 Command block result Field 



While the BCB interface is processing the command initiated by the channel atten- 
tion, it uses the Command_block result field to indicate the status of the command. 
This field has the following bit assignment: 



Bit 


Mnem 


Description 


15 


Complete 


This bit is set by the BCB interface after it completes 
processing the channel attention that the host has issued. 


14 


Busy 


This bit is set to 1 by the BCB interface to indicate it is busy 
processing a channel attention generated by the host. The 
BCB interface sets it to 1 when it begins processing the 
channel attention and to upon completion. 


13 


Status 


This bit is valid only if the Start command was issued and is 
interpreted as follows: 

- the request block has been delivered to iNA. 

1 - the request block has not been delivered to iNA. 


12-0 


— 


Unused. 



When bit 13 (the Status bit) is set to 1, it indicates the BCB interface does not have 
the resources to deliver a request block to iNA. The user should wait for the BCB 
interface to return some outstanding request blocks before trying to send another 
request block. 



9.7.4 A Protocol Implementation 



Apart from conforming to the specifications of the BCB interface, it is up to the user 
to implement his own BCB interface protocol. A possible implementation to deliver 
request blocks to iNA is the following: 

1 . If the Complete bit of the Command_block_response is not 1 , wait for the BCB 
interface to complete processing the previous channel attention. 

2. Check the Status bit of the Command_block_response and handle the error if 
there is one. 

3. Load the Command_address field with the address of the next request block to 
be processed by iNA. 

4. Issue a channel attention to the iNA processor. 



9.7.5 The BCB Interface Initialization Routine 



As part of the initialization process, the BCB interface must be initialized by a user- 
supplied routine. A typical way to initialize would consist of the host putting a 
command at a fixed location in memory, and then generating a channel attention. 
The initialization routine would accept each command and associated parameters 
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and perform the specified initialization chores. Once initialization is complete, iNA 
is started. The user's initialization routine is not called again and subsequent channel 
attentions are processed by the BCB interface. 

The user's BCB interface initialization routine should perform the following: 

1 . It must have a variable named BCBJoc of type DWORD DATA. BCBJoc must 
be initialized to the 32-bit absolute address of the base control block. 

2. Initialize the iNA hardware so that the BCB can be addressed by the iNA 
software. 

3. Call the routine Begin_aim. This will start up the iNA software. The stack size 
when Begin_aim is called must be at least 20 bytes. 



9.7.6 User-Written Routines 



n addition to writing the initialization routine, the user has to write the following 
routines (described in Section 9.9): 

Sys_to_loc_addr 

Loc_to_sys_addr 

Save_address_space 

Restore_address_space 

Gen_int 

Clear int 



9.8 User-Supplied Interface 

If the user does not want to use the MIP or BCB interfaces, he can implement his 
own message delivery mechanism as outlined in this section. To generate the user- 
supplied interface, the user must write the routines detailed in the next section, as 
well as the following: 



CAINT This is the channel attention interrupt service routine that 

is called by iNA upon receiving a channel attention inter- 
rupt from the host. 

Send$to$host$os After processing a request block, iNA calls this routine to 

send the request block back to the host. 

Init_msg_delivery_mech After the iNA software starts running, it calls this routine 

to initialize the user-written MDM. 

In addition, the user must write the initialization code and assemble and link it with 
the rest of the iNA software. 



9.8.1 Initialization 

After system reset, iNA and the message delivery mechanism are in an uninitialized 
state. The user must write, assemble, and link the initialization code to the iNA 
software. The only requirement for this initialization code is that it ends by jumping 
to the routine Begin_aim, which starts up the communication system. 
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9.8.2 CAINT 

The routine CAINT is called by iNA upon receiving a channel attention interrupt 
from the host. This routine is used to prepare the request block for delivery to iNA. 
CAINT can assume the following: 

All registers have been saved on the stack. They are restored from the stack upon 
return from this routine. 

The DS register has been initialized with the base of the data segment. 

An end of interrupt has been issued to the interrupt controller. 

Interrupts have been disabled. 

The return_entity field of the request block can be used and interpreted in any 
way. This field is ignored by iNA. 

CAINT must follow these conventions: 

• It should not use more than 20 bytes of stack. 

It should follow the PL/M-86 COMPACT model of computation. 

It must be named CAINT. CAINT is declared PUBLIC and is linked with the 
rest of the COMM system. 

• If CAINT changes the address window of the iNA processor, it must restore the 
window to the original value. 

• It must not enable interrupts. 

• The request block must be accessible to iNA. If this is not the case, CAINT 
should copy the request block to an onboard request block. The onboard request 
block is then delivered to iNA. 

To deliver the request block to iNA, CAINT makes a call to the routine Ipsend. This 
routine has the following format: 

Ipsend: PROCEDURE (Reserved, Rb_ptr) EXTERNAL; 

DECLARE Reserved BYTE; /* Set to 16 ♦/ 

Rb_ptr POINTER; /* Pointer to request ♦/ 

/♦block ♦/ 

/» Ipsend follows the PL/M-86 COMPACT model 
of computation */ 

END Ipsend; 



9.8.3 Send$to$host$os 

After iNA has completed processing a request block, it calls the routine 
Send$to$host$os to send the request block back to the host. This routine has the 
following form: 

Send$to$host$os: PROCEDURE ( R b_p t r ) ; 

DECLARE Rb_ptr POINTER; /* Pointer to request block */ 

END Send$to$host$os; 
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This routine must follow these restrictions: 

• It must not use more than 20 bytes of stack. 

• It must follow the PL/M-86 COMPACT model of computation. 

• If it changes the address window of the iNA processor, it must restore the address 
window to the original value. 

• If it changes the state of the interrupt flag, it must restore the original value. 

9.8.4 lnit_msg_delivery_mech 

After iNA starts running, it calls the routine Init_msg_delivery_mech. Any initiali- 
zation performed by the message delivery mechanism should be present in this routine. 

9.9 User-Supplied Routines 

Some of the routines that iNA uses depend on the hardware environment. These 
routines are specified in this section and they must be written by the user. Combine 
these routines in the file USERRT.LNK and link this file with the COMM system. 

The user-supplied routines must be written according to the following conventions: 

• They must conform to the PL/M-86 COMPACT model of computation. 

• They must have all CONSTANTS in CGROUP. That is, the ROM option must 
be selected. 

• They must not use more than 20 bytes of stack size. 

• If a routine changes the state of the interrupt flag, it must restore the original 
value before returning. 

9.9.1 Sys_to_loc_addr 

This procedure converts a system address to a local address. If necessary, the address 
space of the iNA processor is reset so the location specified by the system address is 
accessible via the local address. This procedure takes the following form: 

Sy 5_t o_l oc_addr : PROCEDURE ( S y s_a d d r e s 5 ) POINTER PUBLIC; 

DECLARE 

Sy 5_add r e 5 5 DWORD ; 

I F Sy s_addr es s > OFFFFFFH 

THEN DO; /* larger than 1G Mbytes »/ 

/ * 

- mask most significant 8 bits 

- convert least significant 24 bits to a PLM86 POINTER 

- RETURN (PLM86 POINTER) * / 

ELSE DO; /* smaller than 16 Mbytes ♦/ 
/ * 

- note the parameters pertaining to the current address 
space. If this takes more than 1 assembly instruc- 
tion, then this must be done with interrupts disabled 

- set the address space of the iNA processor so that 
the 2 4 bit address Sys_address is accessible by iNA 

- RETURN (the PLM86 POINTER that iNA should use to 
access Sys_address) */ 

END ; 

END S y 5_t o_l o c_a d d r ; 
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9.9.2 Loc_to_sys_addr 

This procedure converts a local address to a system address. The format for this 
procedure is the following: 

Loc_t o_sys_addr : PROCEDURE (Sys_ptr) DWORD PUBLIC; 

DECLARE 

Sys_p t r POINTER; 

/ ♦ 

This routine must convert the PL/M 86 pointer S y s_p t r 
to a 32-bit absolute address, and set the most 
significant byte of the double word to 1. 

* / 

END L o c_t o_5 y 5_a d d r ; 



9.9.3 Save_address_space 

This routine saves the current address space of the iNA processor. Here, the address 
space parameters (see the Sys_to_loc_addr routine) are saved on the stack. When 
this routine is called, the stack is in a form illustrated by the following PL/M-86 
structure: 

DECLARE Stack STRUCTURE ( 

Retur n_a ddress WORD, 

Res t_of_s tack (x)WORD); 

Upon return from this routine, the stack has the following form: 

DECLARE Stack STRUCTURE ( 

S a v e d_p a r a m e t e r s (y) WORD, 
Res t_of_s tack (x)WORD); 

The Save_address_space routine has the following form: 

Save_addres s_space : PROCEDURE PUBLIC; 

/* save the address space parameters on the stack */ 

END S a v e_a d d r e s 5_5 p a c e ; 



9.9.4 Restore address space 

This routine restores the address space of the iNA processor using parameters that 
were stored on the stack by the Save_address_space routine. When this routine is 
called, the stack is in a form illustrated by the following PL/M-86 structure: 

DECLARE Stack STRUCTURE ( 

Retur n_a ddress WORD, 

Saved_parameters (y) WORD, 

Res t_of_s tack ( x) WORD ) ; 

Upon return from this routine, the stack has the following form: 

DECLARE Stack STRUCTURE ( 

Res t_of_s tack (x)WORD); 
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This routine has the following form: 

Res t or e_addr es s_space : PROCEDURE PUBLIC; 

/* restore the address space from the parameters on 

the stack »/ 
END Restore_addre55_space; 

9.9.5 Gen_int 

This routine has the following form: 

Gen_i nt: PROCEDURE PUBLIC; 

/* generate a channel attention to the host */ 

END Gen_i n t ; 

9.9.6 CleaMnt 

This routine has the following form: 

Clear_int: PROCEDURE PUBLIC; 

/♦ if iNA has generated an interrupt to the host, 

then clear the interrupt ♦/ 
END C 1 ea r_i n t ; 



9.10 Configuring the Hardware-Dependent Module 

The hardware-dependent module must be configured for the timer, interrupt control- 
ler, and interrupt controller inputs in the system. This is done with the macros PIT, 
PIC, and PIC_inputs. 



9.10.1 PIT 

PIT configures the hardware-dependent module for the type of programmable inter- 
val timer (PIT) used. This macro has the following form: 

PITCType, Base_port, Increment, Ale, Frequency) 



where 
Type 
Base_port 



Increment 



Ale 
Frequency 



is the type of timer used: 8253 or 80186. 

is a value that depends on the type of timer used. Base_port 
is interpreted as follows: 

8253 - this parameter is the port address of the PIT. 

80186 - this parameter is the base of the 80186 control block 
address. The hardware-dependent module sets the 
control block in I/O space to this value. The least 
significant byte of this parameter must be 0. 

is a value used to specify the other ports of the PIT. These 
ports will be at I/O addresses 

Base_port + (i X Increment) 

where i is a non-negative integer. Increment will usually have 
the value 1 or 2. For the 80186 PIT, this parameter is ignored. 

specifies the timer (0, 1, or 2) used by the hardware- 
dependent module. 

is the frequency in Khz, of the PIT. 
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9.10.2 PIC 

This macro configures the hardware-dependent module for the type of programmable 
interrupt controller (PIC) used. There are currently two supported, the 8259a and 
the PIC in the 80186. If the 80186 is specified as the PIT, it must also be specified 
as the PIC. This macro specifies the master PIC in the system. The data link, timer, 
and host interrupts must all be received at this PIC. This macro has the following 
form: 

PIC (Type, Base_por t , Increment, Buffered) 

where 

Type is the type of programmable interrupt controller, 80186, or 

8259a. 

Base_port is the port address of the PIC. For the 80186 PIC, this 

parameter is ignored. 

Increment is a value used to specify the other ports of the PIC. These 

ports will be at I/O addresses 

Base_port + (i X Increment) 

where i is a non-negative integer. Increment will usually have 
the value 1 or 2. For the 82186 PIC, this parameter is ignored. 

Buffered has the following values: 

'Y' if the PIC supports vectored (cascaded) interrupts. 

'N' if the PIC does not support vectored interrupts. 

9.10.3 PIC_inputs 

PIC_inputs is used to specify the inputs to the PIC. This macro has the following 
form: 

P I C i n p u t 5 (Type, Alc_input, Reserved, Dl_input, 

D l_e d g e_v s_l e v e 1 , Ca_input, C a_e d g e_v s_l e v e 1 ) 



where 



Type is the type of programmable interrupt controller, 80186, or 

8259a. 

ALC_input specifies the pin of the PIC (0-7) that receives interrupts from 

the timer. If the 80186 timer is used, this parameter is 
ignored. 

Reserved must be set to 0. 

DMnput specifies the pin of the PIC (0-7) that receives interrupts from 

the data link controller. 

Dl_edge_vs_level depends on the interrupt at DMnput. It has the following 
value: 

if the interrupt is edge triggered 

1 if the interrupt is level triggered 

This parameter is ignored if the 8259 is used. 

Ca_input specifies the pin of the PIC (0-7) that receives interrupts 

generated by channel attentions from the host. 

Ca_edge_vs_level depends on the interrupt at Ca_input. It has the following 
value: 

if the interrupt is edge triggered 

1 if the interrupt is level triggered 
This parameter is ignored if the 8259 is used. 
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9.1 1 Configuring the Message Delivery Mechanism 

In addition to configuring the hardware-dependent module, the MIP and BCB inter- 
face user must configure the message delivery mechanism. This is done by including 
a macro call to CBA in the configuration file. 



9.11.1 CBA 

The CBA macro is used to specify whether or not the request blocks and buffers are 
accessible by iNA at all times. If not, this macro also specifies the size and number 
of the onboard request block buffers. This macro has the following form: 

CBA (Rb_copy, N u m_r b_b u f f e r 5 , R b_b u f f e r_5 i z e ) 

where 

Rb_copy specifies whether the request blocks and buffers are accessi- 

ble at all times. Values are: 

request blocks and buffers are not accessible at all times. 
Request blocks are copied to onboard request blocks. 

1 request blocks and buffers are accessible at all times. In 
this case the remaining parameters are not used. Request 
blocks are not copied to onboard request blocks. 

Num_rb_buffers specifies the number of onboard request blocks that the 
message delivery mechanism should maintain. This value will 
limit the number of commands that the user can give to iNA 
at the same time. 

Rb_buffer_size is the size of the above buffers. This should be as big as the 
largest request block to be given to iNA. 

If the MIP or BCB interface with the copy option is used for the message delivery 
mechanism, then Rb_copy must be set to 0. In this case, the maximum number of 
request blocks that iNA can process at the same time is limited to Num_rb_buffers. 
Each request block delivered to iNA must be less than Rb_buffer_size bytes in length. 

If Rb_copy is l, then any number of request blocks of any size can be delivered to 

iNA. 

This macro should not be invoked if the user-supplied message delivery mechanism 
is used. 



9.12 Component Support System Generation 

The component support interface is configured and the COMM system is generated 
by the following steps: 

1. Choose the message delivery mechanism. The following are the available options: 

• MIP with request blocks copied to iNA memory. 

• BCB interface with request blocks copied to iNA memory. 

• BCB interface with request blocks not copied to iNA memory. 

• A user-written interface. 
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2. Edit the file :SD:COMM/CONFIG/CMPCFG.A86 to reflect the hardware 
configuration that supports iNA. 

3. The file :SD:COMM/CONFIG/COMM.CSD generates iNA that runs under 
iRMX 86. Make a copy of this file by giving the following command: 

> C D P Y : SD : CQMM/ CDNF I G/COMM . CSD TO 
:SD:COMM/CONFIG/COMMCMP.CSD 



WARNING 



The default configuration and submit files described in this chapter 
assume that the iNA 960 Communication system resides in 
:SD:COMM. If the system is installed on a different directory, or if 
you are an ISIS user, the configuration and submit files must be 
changed to reflect the actual locations of the files they reference. 
For the configuration files, this means the INCLUDE statements 
must be changed. For submit files, the pathname of each file in the 
link list must be changed. 

The file COMM.CSD has the following form: 



ASM86 



SD: CQMM/CDNF IG/RMXCFG. A86 

SD : COMM/ CONF I G/BUFCFG . A86 

SD : COMM/ CONF I G/DLCFG . A86 , 

SD : COMM/ CONF I G/TLCFG . A86 , 
SD : COMM/ C0NFIG/NMLCFG.A86 



L I NK86 



SD 
SD 
SD 
SD 
SD 
SD 
SD 
SD 
SD 



COMM/LNK/COMM . LNK , 4 
COMM/LNK/TL . LNK , 4 
COMM/LNK/TLVC . LNK , 4 
COMM/CONFIG/RMXCFG.OBJ 
COMM/CONFIG/BUFCGF.OBJ 
COMM/CONF I G/DLCFG . OB J , 
COMM/ CONF I G/TLCFG . OB J , 
COMM/LIB/AIMRMX.LIB 4 
COMM/LNK/COMM .LIB 4 



TD :SD:COMM/LNK/COMMCF.LNK 4 
NOCM NOLI NOMAP NQSB 4 
NOPUBLICS EXCEPT (COMMENTRY 



CQERRDRCODE) 



ENTRYPTS, DATA, STACK)) 4 



LDC8G : SD : COMM/ LNK/COMMCF . LNK 4 

TO :SD:C0MM/LNK/C0MM 4 

ORDER ( CLASSES ( CODE 

SEGSIZE (STACK (0)) 4 

ADDRESSES (CLASSES (CODE ( % ) ) ) 4 

NO I N I TCODE , NOL I NES , N0C0MMENTS, N0SYMB0LS 

OB JECTC0NTR0LS (NOLINES, N0C0MMENTS, 4 

NOPUBL ICS, NOSYMBOLS) 



4. Edit the submit file COMMCMP.CSD in the following way. First, replace the 
line: 

ASM8G : SD : COMM/ C N F I G/RMXCFG . A8G 

by 

ASM86 : SD : COMM/ CONF I G/CMPCFG . A86 MACRO(60) 
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5. The LNK invocation to generate COMMCF.LNK links a number of files 
including the following: 

: SD : CQMM/LNK/ A I MRMX . L I B 
: SD : COMM/LNK/RMXCFG . DB J 

Do not link these files while generating COMMCF.LNK. Replace them with the 
following: 

• One of the following: 

:SD:COMM/LNK/MIP.LNK -the MIP message delivery 

mechanism. 

:SD:COMM/LNK/BCBNC.LNK -the BCB interface message deliv- 
ery mechanism without the copy 
option. 

:SD:COMM/LNK/BCBCPY.LNK -the BCB interface message deliv- 
ery mechanism with the copy 
option. 

:SD:COMM/LNK/USRMDM.LNK -the user-supplied message delivery 

mechanism. 

• One of the following: 

:SD:C0MM/LNK/AIM86.OBJ -if iNA runs on an 8086 CPU. 

:SD:C0MM/LNK/AIM186.OBJ -if iNA runs on an 80186 CPU. 

:SD:COMM/LNK/CMPCFG.OBJ -the object file produced by the 

configuration of the component 
support. 

:SD:COMM/LNK/USRRTN.OBJ - this module must contain all the 

user-written routines. 

6. Modify the arguments to the LOC86 command to reflect the hardware 
environment. 

7. To generate the iNA system, type the following: 
>SUBMIT :SD:COMM/CONFIG/COMMCMP.CSD 



9-18 




APPENDIX A 
INA960 FILES 



A. 1 The Delivery Diskettes 



The delivery package contains the following diskettes in both ISIS and iRMX 86 
format: 

iNA 960 Object Code RI.O (COMM) Contains the object code for the Trans- 
port, Data Link, and NMF functions. 

• iNA 960 Object Code RI.O (Boot Consumer) Contains the object code of the 
boot consumer. 



Files on the iRMX 86 formatted diskettes are organized in directories. The same files 
on the ISIS diskettes are flat. Following are the directories on the iRMX 86 diskettes: 



LNK 

CSD 

CONFIG 

LIB 

INC 

INIT 



Contains the iNA 960 core and optional modules. 

Contains the SUBMIT file for installing, linking, and 
locating iNA 960. 

Contains the iNA 960 configuration files. 

Contains the user interface libraries. 

Contains the INCLUDE files for using iNA 960. 

Contains the initialization code for iSBC 1 86/51. 



A.2 Directory LNK 



COMM. LNK Core of iNA 960 object code. 

COMM. LIB Library file required by COMM. LNK. 

BTSRV.LNK Boot server functions. 

TL.LNK Transport core. 

TLVC.LNK Transport normal virtual circuit services. 

TLEX.LNK Transport expedited services. 

TLDG.LNK Transport datagram services. 

EDL.LNK External data link services. 

NMF. LNK Network management functions. 

AIMRMX.LIB Library file required by AIMRMX.LNK. 

AIM186.0BJ AIM-186 module. 

AIM86.0BJ AIM-86 module. 

MIP.LNK MIP module. 

BCBNC.LNK BCBI (non-copy) module. 

BCBCPY.LNK BCBI (copy) module. 



iNA 960 Files 



iNA 960 



A.3 Directory CSD 



INSTALL.CSD 
COMM.CSD 



Submit file to install iNA 960 to hard disk storage. 

Submit file to assemble the configuration files, link all the 
optional modules, and locate the iNA 960. 



A.4 Directory CONFIG 

The following files appear as pairs consisting of a configuration macro definition file 
(MAC extension) and a default configuration file (A86 extension). 



RMXCFG.MAC 
RMXCFG.A86 

CMPCFG.MAC 
CMPCFG.A86 

BUFCFG.MAC 

BUFCFG.A86 

TLCFG.MAC 
TLCFG.A86 

DLCFG.MAC 
DLCFG.A86 

NMFCFG.MAC 
NMFCFG.A86 



Configuration file to configure iNA 960 in the iRMX 86 
environment. 

Configuration file to configure iNA 960 in the component 
support environment. 

iNA 960 buffer configuration file. 
Transport configuration file. 
Data link configuration file. 
NMF configuration file. 



A.5 Directory LIB 



CQC.LIB 
CQL.LIB 



iNA 960 user interface library for PLM-86 COMPACT 
mode. 

iNA 960 user interface library for PLM-86 LARGE and 
MEDIUM modes. 



A.6 Directory INC 

CQRB.EXT External declarations for request block interfaces. 

CQTL.EXT External declarations for transport procedure interfaces. 

CQDL.EXT External declarations for data link procedure interfaces. 

CQNMF.EXT External declarations for NMF procedure interfaces. 

CQTL.LIT Literal declarations for transport interface parameters. 

CQNMF.LIT Literal declarations for NMF interface parameters. 



A.7 Directory INIT 



ICODE.OBJ 

IN186.MAC 

IN186.A86 

INIT.CSD 



Initialization code for iSBC 186/51. 
Configuration files for the initialization code. 

Submit file for linking and locating the init code. 
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A. 8 The Boot Consumer Diskette 

The configuration file for the boot consumer. 
The boot consumer. 



CNFG.A86 
CNFG.MAC 



ROMA.OBJ 
ROMB.OBJ 

AUTBOT.OBJ 
AUTBOT.P86 
AUTBOT.LST 

ROM.CSD 



A sample user-written main module. 



The submit file to link and locate the boot consumer. 
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APPENDIX B 

NETWORK MANAGEMENT 

FACILITY OBJECTS 



B.1 NMF/ Data Link Objects 



Id 


Type 


Access 


Size 


Description 


2000H 


value 


R 


BYTE 


Data Link Type. Reserved for future expan- 
sion. Set to 1. 


2001 H 


value 


R 


DWORD 


Line Speed. The physical transmission rate in 
bits/second. 


2002H 


value 


R 


48 BIT 


Host Id. The network physical address. 


2003H 


counter 
(wraparound) 


RC 


DWORD 


Total Sent. Total number of packets sent by 
the station. 


2004H 


counter 
(sticky) 


RC 


WORD 


Primary Collisions. The number of packets 
transmitted by the station that had at least 1 
collision. 


2005H 


counter 
(sticky) 


RC 


WORD 


Secondary Collisions. The number of colli- 
sions encountered after each primary 
collision. 


2006H 


counter 
(sticky) 


RC 


WORD 


Exceeded Collisions. The number of packets 
discarded because the maximum number of 
collisions was exceeded. 


2007H 


counter 
(wraparound) 


RC 


DWORD 


Total Received. The number of packets 
forwarded from the network to the client. 


2008H 


counter 
(sticky) 


RC 


WORD 


CRC Errors. The number of packets dropped 
because of CRC errors. 


2009H 


counter 
(sticky) 


RC 


WORD 


Alignment Errors. The number of packets 
dropped due to alignment errors. 


200AH 


counter 
(sticky) 


RC 


WORD 


Resource Errors. The number of times data 
link ran out of resources. 



B.2 NMF/Transport Virtual Circuit Connection 
Independent Objects 



Id 


Type 


Access 


Size 


Description 


4000H 


value 


R 


BYTE 


Virtual Circuit Type. Set to 0. 


4001 H 


value 


R 




Connection ID Vector. WORD array where each 
nonzero element is an allocated connection ID. 
The size of this object is as follows: 
(2 X max_connections) BYTES 


4002H 


value 


R 


BYTE 


ISO Transport Number. The version number of 
the ISO virtual circuit subsystem. 


4003H 


value 


R 


WORD 


Maximum Connections. The maximum number 
of connections supported by the virtual circuit 
subsystem. 


4004H 


value 


R 


WORD 


Current Maximum Connections. The maximum 
number of connections currently available. 


4005H 


value 


R 


WORD 


Maximum On-board CDB's. The number of 
connection databases that have space already 
allocated (on-board). 



Network Management Facility Objects 



iNA 960 



B.2 NMF/Transport Virtual Circuit Connection 
Independent Objects (Cont'd.) 



Id 


Type 


Access 


Size 


Description 


4006H 


value 


R 


WORD 


Active CDB's. The number of connection 
databases currently in use. 


4007H 


value 


R 


WORD 


CDB Size. The size in bytes of a connection 
database. 


4008H 


parameter 


RS 


WORD 


Default Persistence Count. The number of times 
the local transport entity attempts to establish a 
connection when the remote transport entity 
explicitly rejects the connection attempt. It is 
assigned to new connections that request default 
persistence count. 


4009H 


parameter 


RS 


WORD 


Default Abort Timeout. The amount of time (in 
units of 51 ms.) an unacknowledged segment is 
transmitted before automatically aborting the 
connection. It is assigned to new connections 
that request default abort timeout. A value of 
OFFFFH indicates that an automatic abort is 
never to occur. 


400AH 


parameter 


RS 


DWORD 


Default Retransmit Timeout. The initial amount 
of time (in units of 100 ms.) the transport layer 
waits before retransmitting an unacknowledged 
segment. This value is used on all new connec- 
tions. 


400BH 


parameter 


RS 


DWORD 


Minimum Retransmit Timeout. The minimum time 
(in units of 100 ms.) the transport layer waits 
before transmitting an unacknowledged 
segment. The initial value is configurable, but 
may be reset by the user. 


400CH 


parameter 


RS 


WORD 


Closing Abort Timeout. The amount of time (in 
units of 51 ms.) the transport layer waits after 
sending a connection close request before 
aborting the connection. 


400DH 


parameter 


RS 


DWORD 


Flow Control Window Timeout. Once a connec- 
tion is established, the local transport sends flow 
control window acknowledgement packets to the 
remote entity at regular intervals to signal to the 
remote entity that it is still functioning when no 
other activity is on the connection. These 
packets also inform the remote transport of the 
most current local flow control window status. 
This object specifies the time interval (in units of 
1 00 ms.) between these packets. 


400EH 


parameter 


RS 


WORD 


Inactivity Maximum Count. The number of times 
the local transport transmits an unacknow- 
ledged flow control window acknowledgement 
packet before aborting the connection. 


400FH 


counter 
(sticky) 


RC 


WORD 


Total Duplicate Segments Rejected. The total 
number (over all connections) of received 
segments that were rejected due to duplicate 
sequence numbers. 


401 OH 


counter 
(sticky) 


RC 


WORD 


Total Checksum Errors. The total number (over 
all connections) of received segments that were 
rejected because of checksum errors. 


401 1H 


counter 


RC 


WORD 


Total Retransmission. The total (sticky) number 
of times (over all connections) that unacknow- 
ledged segments were retransmitted. 
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B.2 NMF/Transport Virtual Circuit Connection 
Independent Objects (Cont'd.) 



Id 


Type 


Access 


Size 


Description 


401 2H 


counter 
(sticky) 


RC 


WORD 


Total Resource Errors. The total number (over 
all connections) of segments discarded because 
receive buffers were not available. 


401 3H 


value 


R 


BYTE 


Maximum Network Address Length. The 
maximum length of the network address. 


4014H 


value 


R 


BYTE 


Maximum TSAP-ID Length. The maximum length 
of local or remote TSAP-ID's. 


401 5H 


value 


R 


WORD 


Local NSAP-ID. The local NSAP-ID required to 
interface to the underlying network layer. 


401 6H 


value 


R 


BYTE 


Reserved. 


401 7H 


value 


R 


BYTE 


Reserved. 


401 8H 


parameter 


RS 


WORD 


Default Connection Negotiation Options. Speci- 
fies the default connection negotiation options. 


4019H 


parameter 


RS 


BYTE 


Maximum TPDU Size. The value (specified as a 
power of 2) used for maximum TPDU size in the 
negotiation phase of connection establishment 
by the local transport entity. 


401AH 


parameter 


RS 


BYTE 


No Additional Option Field. An additional option 
field (as encoded in ISO 8073) used as an 
assumed additional option parameter requested 
by a remote entity when, in fact, no such option 
parameter has been provided in the request. 


401 BH 


parameter 


RS 


BYTE 


No Maximum TPDU Size Field. The maximum 
TPDU size (specified as a power of 2) used as 
an assumed maximum TPDU size requested by 
a remote entity when, in fact, no size was speci- 
fied by the remote entity in its request. 


401 CH 


parameter 


RS 


WORD 


Maximum Normal Window Size. The largest 
receive buffer credit that can be reported on a 
connection by the local TS to a remote TS for 
normal sequence number format. 


401 DH 


parameter 


RS 


WORD 


Maximum Extended Window Size. The largest 
receive buffer credit that can be reported on a 
connection by the local TS to a remote TS for 
extended sequence number format. 


401 EH 


parameter 


RS 


WORD 


Minimum Credit. The smallest receive buffer 
credit that can be reported on a connection by 
the local TS to a remote TS. This object has the 
following values: 

— window can close 

1 — window can never close 


401 FH 


parameter 


RS 


DWORD 


Open Window Timeout. The interval (in units of 
100 ms.) between successive acknowledge- 
ments (AK TPDU's) that announce the opening 
of a previously closed credit window to avoid 
flow control deadlock. 


4020H 


parameter 


RS 


WORD 


Maximum Open Window Count. The maximum 
number of open window AK's transmitted before 
the sender assumes that the remote TS has 
received the open window credit information. 
When this count is reached, the local TS stops 
transmitting the open window AK's. 
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Dependent Objects 



Id 


Type 


Access 


Size 


Description 


4081 H 


value 


R 


— 


Local TSAP-ID. The local TSAP-ID for the speci- 
fied connection. 


4082H 


value 


R 




Remote Network Address. The network address 
of the entity at the remote end of the connection. 
If the user performs a partially specified or 
unspecified passive open, this object will be until 
the connection is established. 


4083H 


value 


R 


— 


Remote TSAP-ID. The remote TSAP-ID for the 
specified connection. 


4084H 


value 


R 


BYTE 


Connection State. The state of the connection. 
This object has the following values: 

— Listen 5 — Closed 

1 — Cr Sent 6 — Open 

2 — Ack Wait 7 — Calling 

3 — Estab 8 — Cr Received 

4 — Closing 


4085H 


value 


R 


WORD 


Remote Connection ID. The connection ID of the 
remote end of the specified connection. This 
object is set after the connection is established. 


4086H 


parameter 


RS 


WORD 


Persistence Count. The number of times a 
connection request is retransmitted when the 
remote entity explicitly refuses it. 


4087H 


parameter 


RS 


WORD 


Abort Timeout. This has the same meaning as the 
default abort timeout, but it is the actual abort 
timeout used on a specific connection. 


4088H 


parameter 


RS 


WORD 


Retransmit Timeout. This has the same meaning 
as the default retransmit timeout, but it is the 
actual retransmit timeout used on a specific 
connection. 


4089H 


value 


R 


WORD 


Next Transmit Sequence Number. The sequence 
number to be used with the next segment to be 
transmitted (not always the highest). 


408AH 


counter 
(sticky) 


RC 


WORD 


Duplicate Segments Rejected. The total number 
of duplicate received segments discarded by 
transport on the specified connection. 


408BH 


counter 
(sticky) 


RC 


WORD 


Segments Retransmitted. The total number of 
times that an unacknowledged segment has been 
retransmitted over the specified connection. 


408CH 


counter 
(sticky) 


RC 


WORD 


Resource Errors. The total number of times that 
segments received on the specified connection 
were rejected because receive buffers were not 
available. 


408DH 


value 


R 


WORD 


Client Options. The options specified by the client 
at the time the connection request was made. 


408EH 


value 


R 


BYTE 


Class Options. The ISO class of services and 
sequence number format actually negotiated on 
the connection. The only values are as follows: 
40 — class 4 and normal (7-bit) format 
42 — class 4 and extended (31 -bit) format 


408FH 


value 


R 


BYTE 


Additional Options. The additional options actually 
negotiated on the connection. Only bits and 1 
are meaningful. The values are as follows: 

— no expedited service and checksum 

1 — expedited service and checksum 

2 — no expedited service and no checksum 

3 — expedited service and no checksum 
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B.3 NMF/Transport Virtual Circuit Connection 
Dependent Objects (Cont'd.) 



Id 


Type 


Access 


Size 


Description 


4090H 


value 


R 


BYTE 


Maximum TPDU Size. The negotiated maximum 
TPDU size (as a power of 2) over the connection. 


4091 H 


value 


R 


WORD 


Maximum TPDU Data Length. The maximum 
length (in bytes) of the data that can be sent in 
one TPDU; that is, the maximum TPDU size minus 
the header length. 


4092H 


value 


R 


WORD 


Inactivity Count. The number of times an unack- 
nowledged flow control window acknowledge- 
ment packet has been retransmitted over the 
connection. 


4093H 


value 


R 


— 


Reserved. 



B.4 NMF/Transport Datagram Objects 



Id 


Type 


Access 


Size 


Description 


4100H 


value 


R 


BYTE 


Datagram Type. Set to 1 . 


4101H 


value 


R 


BYTE 


Datagram Receive Queue Size. The maximum 
number of TSAP-ID's for which the client can post 
buffers. 


4102H 


value 


R 


BYTE 


Reserved. 


4103H 


counter 
(sticky) 


RC 


WORD 


Total Datagrams Transmitted. The total number of 
datagrams transmitted. 


4104H 


counter 
(sticky) 


RC 


WORD 


Total Datagrams Received. The total number of 
datagrams received. 


4105H 


counter 
(sticky) 


RC 


WORD 


Total Datagram Resource Errors. The total number 
of datagrams rejected due to lack of buffers. 


4106H 


counter 
(sticky) 


RC 


WORD 


Total Datagram Checksum Errors. The total 
number of datagrams rejected due to checksum 
errors. 


4107H 


counter 


RC 


WORD 


Total Datagram Address Errors. The total number 
of datagrams rejected due to illegal address fields 
in the header. 



B.5 NMF/Boot Server Objects 



Id 


Type 


Access 


Size 


Description 


8000H 


value 


R 


WORD 


NMF Type. Reserved for future expansion. Set 
to1. 


8001 H 


value 


R 


6 BYTES 


Multicast Address of the boot server. Set at 
configuration time. 


8002H 


value 


R 


WORD 


Maximum Number of Nodes that the boot 
server can boot at the same time. Set at config- 
uration time. 


8003H 


value 


R 


WORD 


Maximum Number of Addresses in the boot 
table. 
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B.5 NMF/Boot Server Objects (Cont'd.) 



Id 


Type 


Access 


Size 


Description 


8004H 


parameter 


RS 


— 


The Boot Table. The first WORD specifies the 
number of addresses in the table. 


8005H 


value 


R 


WORD 


Number of Class Codes recognized by the boot 
server. Set at configuration time. 


8006H 


value 


R 




List of Class Codes that the boot server recog- 
nizes. The size of this object is 2X number of 
class codes BYTES. Set at configuration time. 


80FFH 


value 


R 


WORD 


Number of NMF's present in the system. 
Reserved for future expansion. Set to 1 . 
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APPENDIX C 

SAMPLE USER ROUTINES 

FOR COMPONENT SUPPORT 



This appendix contains sample user-written routines for the iSBC 552. Use these 
routines as a guideline when writing routines for your own specific hardware. 

The iSBC 552 offers a low-cost Ethernet controller module for MULTIBUS-based 
systems. The iSBC 552 has the following features: 

• 8 MHz 80186/82586 co-processors 

• 82501 Ethernet Serial Interface chip 

• 16 data bit/24 address bit MULTIBUS master capability 

• 256 Kbytes of RAM/ROM 

The iSBC 552 is totally memory-mapped. Local address bits 18 and 19 are decoded 
to divide the 1 -Mbyte 80186 memory space into four 256-Kbyte quadrants. The upper 
quadrant (768K to 1M) and lower quadrant (0 to 256K) are used solely for local 
memory and will access the same physical memory. Quadrant 2 (256K to 512K) is 
used for memory-mapped local I/O. Quadrant 3 (512K to 768K) is used as the 256K 
window to the 16-Mbyte MULTIBUS memory. 

The listings consist of 4 modules. The first module, BOOT_START, contains the 
initialization code for the BCBI interface and the routines GEN_INT and 
CLEARJNT. 

The second module, INITIALIZE_552, contains the routine that initializes the chip- 
select lines of the 80186 processor. 

The third module, LOC_TO_SYS_ADDR_FOR_552, contains the routine 
LOC_TO_SYS_ADDR. 

The last module, COPY, contains the routines SYS_TO_LOC_ADDR, 
SAVE_ADDRESS_SPACE, and RESTORE_ADDRESS_SPACE. 

SERIES-III 8086/8087/8088 MACRO ASSEMBLER V1.1 ASSEMBLY DF MODULE 

B00T_START NO OBJECT MODULE REQUESTED 

ASSEMBLER INVOKED BY: ASM8G.8G : F 1 : L L I B T . A 8 G P A G E W I D T H ( 7 8 ) N00J 



L0C OBJ 



LINE 

1 

2 

3 

4 

S 

6 

7 

8 

9 

1 

1 1 

1 2 

1 3 

1 4 

1 5 

16 



SOURCE 
NAME 



B00T_START 



11)11! 



MODULE NAME: BOOT START ENTRY 

FUNCTION: THIS IS THE START OF THE 
MAI N PROGRAM . IT ASSUMES THAT 
INA HAS ALREADY BEEN LOADED 
ONTO THE R AM . 



11111111111 



CGROUP GROUP CODE 
DGROUP GROUP DATA 
ASSUME CS:CGR0UP, DS : DGROUP 



C-l 



Sample User Routines for Component Support iNA 960 



1 7 

18 DATA SEGMENT PUBLIC 'DATA' 

19 

0000 ?? 20 SAVED_I N T_T Y P E DB ? 

0001 ???? 21 S A V E D_I NT_ADDR DW ? 

22 
0003 (40 23 MY_STACK DW 40 DUP (?) 

? ? ? ? 
) 
0053 24 MY_STACK_TOP LABEL WORD 

25 

2 6 PUBLIC INIT_WINDOW BCB_L0C 

53 (2 2 7 INIT_WINDOW DW 2 DUP (?) 

? ? ? ? 

) 
0057 (2 28 BCB_L0C DW 2 DUP (?) 

9 9 9 9 
) 

29 
30 DATA ENDS 

3 1 

3? 

33 ;; LITERAL DECLS USED BY THIS ROUTINE 

)J)11JJ)J11I)1117)11I)J1JJ)))11J1)11)) 



34 
35 

FF22 3G P I C_E I_P EQU 0FF22H 

37 EXTRN CA_I N T_V E C T R_T Y P E 
:ABS -, CNFG PARM 

FFFF 38 MASK_ALL_I NTS EQU 0FFFFH 

39 

FF28 40 PIC_MASK_P EQU 0FF28H 

4 1 EXTRN ENABLE_CA : ABS 

; CNFG PARM 
42 

FF24 43 P I C_P D L L_P EQU 0FF24H 

44 EXTRN I NT_FROM_USER : ABS 

; CNFG PARM 
45 

0800 46 SCP_0_OFF EQU 0800H 

1000 47 SCP_1_OFF EQU 1 00 OH 

180 4 8 SC'P_2_0FF EQU 180 OH 

4 4 9 SCP_BASE EQU 4 OH 

40 50 BASE_552 EQU 4 OH 

5 1 

2100 52 LED_ADDR EQU 2100H 

2 102 53 MB_W I NDOW EQU 2 1 02H 

2104 54 MB_IO_ENABLE EQU 2104H 

2106 55 MB_I 0_DI SABLE EQU 2106H 

2108 56 MB_I NT_D I SABLE EQU 2108H 

210A 57 MB_I NT_ENABLE EQU 210AH 

58 

59 I SCP_STR STRUC 

60 BUSY DB ? 

000 1 6 1 STATUS DB ? 

0002 62 SCB_OFFSET DW ? 

0004 63 SCB_BASE_1 DW ? 

0006 64 SCB_BASE_2 DB ? 

0007 65 UNUSED_1 DB ? 

0008 66 INT_TYPE DB ? 
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iNA 960 



Sample User Routines for Component Support 



09 
A 



00 

5E 

1 58 

02 5 A 

03 BF 04 

06 8EC7 

08 BF 022 1 

000B 2688 1 5 

0E B208 

10 

00 10 B90C00 

13 50 



14 

00 14 F8 

15 D 1D0 

00 17 D1D2 

00 19 E2F9 



00 1B 58 

1 C 250F0 

00 1 F 8BD8 

02 1 8EC2 

0023 FFE6 



025 

0025 FA 

0026 B8 



67 
68 
69 
70 

7 1 
72 
73 
74 
75 
76 
77 
78 
79 
80 

8 1 
82 
83 
84 
85 
86 
87 



89 
90 
9 1 
92 
93 
94 
95 
96 

97 
98 
99 

1 00 
1 1 
1 02 
1 03 
1 04 
1 05 
1 06 
1 07 
1 08 
1 09 
1 1 
1 1 1 
1 1 2 
1 1 3 
1 1 4 
1 1 5 
1 16 
1 1 7 
1 18 
1 19 
1 20 
12 1 
122 



UNUSED_2 

I NT_ADDR 

I S C P_S T R ENDS 



DB ? 
DW ? 



CODE SEGMENT BYTE PUBLIC 'CODE' 

EXTRN CONFIDENC E_T E S TS : NEAR 

EXTRN INI T_HARD : NEAR 

EXTRN BEG I N_A I M : NE AR 

EXTRN S Y S_T 0_L C_A DDR : NEAR 

I ! 1 1 1 5 1 ! ! ! 1 ) 5 ! 1 ! 1 1 1 1 1 I I 5 ! 1 I I I 1 I I )) I 1 I 1 

;; SETS THE MBUS WINDOW AND RETURNS 
: ; PTR TO ACCESS THE LOCATION 



SET_W I NDOW : 
POP SI 
POP AX 
POP DX 



THE RETURN ADDRESS 
THE LSW 
THE MSW 



MOV DI , BASE_552 ; SET THE MBUS 
W I NDOW 

MOV ES , D I 

MOV D I , MB_W I NDOW 

MOV BYTE PTR ES:[DI], DL 



MOV DL , 8 

STLA_1 : 

MOV CX , 12 
PO I NTER 

PUSH AX 



MBUS MAPPING AT 80000? 

CONVERT LOW(DL) : BX TO 
SAVE LSW 



; GET BASE OF THE POINTER IN THE DX 
REGI STER 
STLA_2 : 

CLC 

RCL AX , 1 

RCL DX , 1 

LOOP STLA_2 

; GET THE OFFSET OF THE POINTER IN AX 
POP AX 
AND AX , OFH 



MOV BX , AX 
MOV ES , DX 

JMP S I 



RETURN AS POI NTER 



RETURN 



) ! 1 ) ) I 1 ) 1 1 I 1 1 1 1 1 

; ; THE BEGI NN I NG 



i i i ) i i i i i i i 



) ) I 1 ) 1 ] 1 ) ) ! ) 1 7 I ! I ) ) 1 ] 1 ! ! 1 1 1 ! 1 1 ! 1 ) ! ) 1 1 1 

PUBLIC BOOT_START_ENTRY 
BOOT_START_ENTRY : 
CL I 

MOV AX, DGROUP ; INIT SS,DS AND SP 



C-3 



0029 8ED8 
2 B 8ED0 
002D BC5300 



0030 50 



0031 
0034 
037 

038 
03B 
03B 
03C 
040 



045 
048 



04C 
004E 
005 1 
0054 
0057 

005A 
005D 
0060 

00G2 
0063 
0064 

0067 
0068 



0070 
073 
077 



007E 
0082 
8 4 
0088 

008B 
08E 



B80000 
BA28FF 

EF 

BA24FF 

ED 

8 1 F20 00 

75F9 



042 B8000 



BA22FF 
EF 



0049 BB0040 



8EC3 
BB0008 
268A07 
BB00 1 
268A27 

BBOO 18 
268A 1 7 
32F6 

52 
50 
E899FF 

58 
2688470 1 



006C 268A4708 



A200 00 
268B470A 
A30 1 



07A 268B4704 



268A5706 
32F6 

26034702 
83D200 

A3570 
89165900 



0092 C70653000000 R 



1 23 
1 24 
1 25 
1 26 
1 27 
1 28 
1 29 
1 30 
1 3 1 
1 32 
1 33 
1 34 
1 35 
1 36 
1 37 
1 38 
1 39 
1 40 

1 4 1 

1 42 

1 43 

1 44 

1 45 

1 46 

1 47 

1 48 

1 49 

1 50 
1 5 1 
1 52 
1 53 
1 54 
1 55 
1 56 
1 57 
1 58 
1 59 
160 
161 

162 
163 
164 
165 
166 

167 
1 68 
1 6 9 
1 70 
1 7 1 
1 72 
1 73 
1 74 
1 75 



MOV DS , AX 
MOV SS , AX 
MOV SP, OFFSET D G R U P : M Y_S T A C K_T P 



SAVE RESULT 
UNMASK CA 



; CALL CONF IDENCE TESTS 
PUSH AX 

MOV AX , EN ABLE_CA 
MOV DX, PIC_MASK_P 
OUT DX , AX 

MOV DX, PIC_POLL_P 
WA I T_CA : 

IN AX , DX 

XOR DX, I NT_FROM_USER 

JNE W A I T_C A 



MOV AX, CA_I NT_VECTOR_TYPE ; EOI THE 
P I C 

MOV DX , PI C_EO I_P 

OUT DX , AX 

MOV BX, SCP_BASE ; GET SCP AS 
DWORD 

MOV ES, BX 

MOV BX, SCP_0_OFF 

MOV AL, BYTE PTR E S : [B X] 

MOV BX, SCP_1_0FF 

MOV AH , BYTE PTR ES :[BX] 

MOV BX, SCP_2_0FF 

MOV DL, BYTE PTR ES:[BX] 

XOR DH , DH 



GET PTR TO I SCP 



PUSH DX 
PUSH AX 
CALL SET_WINDO 



POP AX ; RESULT OF CONFIDENCE TEST 

MOV ES :[BX]. STATUS , AL 

MOV AL, E S : [B X] . IN T_T Y P E ; SAVE INT 
INFO 

MOV SAVE D_I NT_TYPE , AL 

MOV AX , ES :[BX]. I NT_ADDR 

MOV SAVE D_I NT_ADDR , AX 

MOV AX, E S : [B X] . S C B_B A S E_1 ; GET BC 
ADDR 

MOV DL , ES : [BX ] . SCB_BASE_2 

XOR DH , DH 

ADD AX, ES :[BX]. S C B_0 F F S E T 

ADC DX , 

MOV BCB_LOC, AX ; AND SAVE IT 

MOV BCB_L0C+2, DX 

MOV I N I T_W I NDOW , ; NOTE THE VALUE 
OF INITIAL UI NDOW 
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0098 89 165500 

09C 2GC6070 

00A0 52 

00 A 1 50 

00A2 E85BFF 

0A5 E900 



AB 

A8 BBO 04 

AB 8EC3 

AD AO 0000 

OBO 8B 1G0 1 00 

00B4 FEC8 

0B6 740B 

00B8 FEC8 

OBA 74 1D 



R 1 7G 
1 77 
1 78 
1 79 
180 

1 8 1 

182 

183 

E 184 

185 
1 86 
187 
1 88 
189 
1 90 
1 9 1 



1 92 
1 93 
194 
195 
1 96 



197 
1 98 

199 



MOV IN I T_W I NDOW + 2 , DX 

MOV ES :[BX]. BUSY , 0; CLEAR BUSY BIT 



PUSH DX 
BCB 

PUSH AX 

CALL S E T_W I N DO W 

JMP BEGI N_A I M 
SYSTEM 



; SET U I NDOW TO 



; START COMM 



; ; GENERATES I NT TO HOST 



7 7 7 7 7 1 1 7 7 7 7 1 7 7 7 1 7 1 ) 7 7 7 7 1 

PUBL I C GEN_I NT 
GEN_I NT : 

MOV BX , BASE_552 
4 OH 

MOV ES , BX 



I N I T ES WITH 



MOV AL, SAVE D_I N T_T Y P E 

MOV DX, SAVE D_I NT_ADDR 

DEC AL ; I F AL - 1 THEN 

MEM MAPPED 

JZ MEM_MAPPED_I NT 

DEC AL ; I F A L = 2 THEN 

I/O MAPPED 

JZ I 0_MAPPED_I NT 



OBC BBO A2 1 

OOBF 2688 1 F 
00C2 C3 



0C3 
0C3 
0C6 
OOCA 
OOCC 
OCF 
00D0 
00D1 
0D4 
00D8 

0D9 
00D9 
OODC 
ODF 
00E0 
00E3 
0E6 



A 1 5700 

8B0E5900 

03C2 

83D1 00 

5 1 

50 

E80000 

26C607FF 

C3 



BB042 1 
26881 F 
EE 

BB062 1 
2688 1 F 
C3 



20 
20 1 

202 
203 
204 
205 
206 
207 
208 
209 
2 1 
2 1 1 
2 1 2 
2 1 3 
2 1 4 
2 1 5 
2 1 6 
2 1 7 
2 1 8 
2 1 9 
220 
22 1 
222 
223 
224 
225 
226 
227 



MOV BX, MB_I NT_ENABLE ; ELSE LEVEL 
MODE 

MOV BYTE PTR ES:[BX], BL 
RET 

MEM MAPPED INT: 

MOV AX , BCB_LOC 

MOV CX, BC B_L C + 2 

ADD AX , DX 

ADC CX , 

PUSH CX 

PUSH AX 

CALL S Y S_T D_L D C__A DDR 

MOV BYTE PTR ES:[BX], OFFH 
RET 

I 0_MAPPED_I NT : 

MOV BX, MB_I0_ENABLE 

MOV BYTE PTR ES:[BX], BL 

OUT DX , AL 

MOV BX, MB_I 0_D I SABLE 

MOV BYTE PTR E S : [B X] . BL 

RET 

7 7 J 7 7 1 J 7 7 7 5 7 7 7 7 7 7 7 7 7 7 1 7 1 7 7 7 1 1 7 7 7 1 7 1 7 7 J 

; ; CLEARS THE INT GENED TO HOST 

) ) 1 1 1 1 ) 1 ! 1 I ! 1 ! ) 1 1 1 1 ! I I I 1 ) 1 1 1 ) 1 ) 1 1 1 I ) ) ) 

PUBL I C C L E A R_I NT 



C-5 



00E7 

00E7 AOOOOO 

OEA ACO 

OOEC 750B 

OOEE BB0040 

OOF 1 8EC3 
OOF3 BB082 1 

OOF6 2G881 F 

OOF9 

OOF9 C3 



228 
229 
230 

23 1 
232 
233 
234 
235 
236 
237 
238 
239 
240 

24 1 
242 
243 



CLEAR_I NT: 

MOV AL, SAVED_I N T_T Y P E 
OR AL , AL 
JNZ CI 1 

MOV BX, BASE_552 

MOV ES , BX 

MOV BX, MB_I N T_D I SABLE 

MOV BYTE PTR ES:[BX], BL 

C I_1 : 
RET 

CODE ENDS 

END BOOT_START_ENTRY 



ASSEMBLY COMPLETE, NO ERRORS FOUND 



SERIES-I I I 808G/8087/8088 MACRO ASSEMBLER V1.1 ASSEMBLY OF MODULE 

INITIAL I Z E_5 5 2 

NO OBJECT MODULE REQUESTED 

ASSEMBLER INVOKED BY: ASM86.86 : F 1 : I N I 5 5 2 . A 8 6 P A G E W I D T H ( 7 8 ) NOOJ 



LOC OBJ 



FFAO 
C038 

FFA2 
3FF8 

FFA8 
81 F8 

FFA6 
4 1 F8 

FFA4 



LINE 

1 

2 

3 

4 

5 

6 

7 

8 

9 

1 

1 1 

1 2 

1 3 

1 4 

1 5 

16 

1 7 

•1 8 

1 9 
20 

2 1 
22 
23 
24 
25 
26 
27 
28 
29 
30 

3 1 
32 



SOURCE 

NAME INITIAL IZE_552 



iiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 

MODULE NAME : 

INITIALIZES THE 552 BOARD . 

FUNCTION: THIS MODULE 

I N I T_HARD- INITIALIZES THE 
PCS AND MCS OF THE 80 186 



CGROUP GROUP CODE 
ASSUME CS : CGROUP 



))]))) 



1)71) 



L I TERAL DEFS FOR HARDWARE 
INITIAL IZATI ON 



111111111111111 

UMCS_P 


11111 
EQU 


UMCS_VAL 


EQU 


LMCS_P 


EQU 


LMCS_VAL 


EQU 


MPCS_P 


EQU 


BLOC K_S I ZE_8K 


EQU 


MMCS_.P 


EQU 


MCS_BASE 


EQU 


PACS_P 


EQU 



1111111 

OFFAOH 
OC 038H 

0FFA2H 
03FF8H 

0FFA8H 
08 1 F8H 

0FFA6H 
04 1 F8H 

0FFA4H 
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4228 



0000 

0000 B838C0 

0003 BAAOFF 

OOOG EF 

007 B8F83F 

OOA BAA2FF 

OOOD EF 

OOE B8F881 

11 BAA8FF 

14 EF 

15 B8F84 1 

18 BAAGFF 

1B EF 

1 C B82842 

1 F BA A4FF 

022 EF 

0023 C3 



33 
34 
35 
36 
37 
38 
39 
40 

4 1 
42 
43 
44 
45 
46 
47 
48 
49 
50 

5 1 
52 
53 
54 
55 
56 
57 
58 
59 
60 

6 1 
62 
63 
64 
65 
66 
67 
68 
69 
70 



PCS_BASE EQU 04228H 

CODE SEGMENT BYTE PUBLIC ' CODE ' 



) ! ) ! ! I I I ! I I I 1 ! ! 1 1 



INITIALIZES THE 552 HARDWARE, THE 

PCS AND MCS 

this consists of initializing the 

chip selects lines of the 80186, 

sets the esi chip 

into non loop back mode. 



1 ) ) J J 1 1 ] ) ! 1 ] 1 1 1 

PUBL I C INI T_HARD 
I N I T HARD : 



MOV AX 
MOV DX 
OUT DX 



MOV AX 

MOV DX 

OUT DX 

MOV AX 

MOV DX 

OUT DX 

MOV AX 

MOV DX 

OUT DX 

MOV AX 

MOV DX 

OUT DX 

RET 



UMCS_VAL 

UMCS_P 

AX 



LMCS_VAL 

LMCS_P 

AX 

BLOCK_S IZE_8K 

MPCS_P 

AX 

MCS_BASE 

MMCS_P 

AX 

PCS_BASE 

PACS_P 

AX 



CODE ENDS 
END 



ASSEMBLY COMPLETE, NO ERRORS FOUND 



SERIES-III 8086/8087/8088 MACRO ASSEMBLER V 1 . 1 ASSEMBLY OF MODULE 

LOC_TO_S YS_ADR_F0R_552 

NO OBJECT MODULE REQUESTED 

ASSEMBLER INVOKED BY: ASM86.86 :F1:LTSA.A86 P A G E U I D T H ( 7 8 ) NOOJ 



LOC OBJ 



LINE 

1 
2 
3 
4 
5 
6 
7 
8 
9 
1 



SOURCE 

NAME LOC T0_SYS_ADR_F0R_552 



! ) ) 1 1 1 I 1 1 1 



) ! ) ) I ) I ! ! ] ! 1 1 1 1 



MODULE NAME: 

LOCAL TO SYSTEM ADDRESS 

FUNCTION: 

CONVERTS PLM86 POINTER TO A 32 
BIT ABSOLUTE ADDRESS AND THEN 
SETS BIT 25 TO 1 



C-7 





0000 5F 

000 1 5E 

002 B8 

0003 33D2 

00 05 B90400 
0008 

0008 F8 

009 D 1 DO 

0. B D 1 D 2 

OOOD E2F9 

OF 03C6 

00 11 8 1 D2000 

00 15 8BD8 

00 17 8EC2 

19 FFE7 



1 1 
1 2 
1 3 
1 4 
1 5 
1 G 
1 7 
18 

1 9 
20 

2 1 
22 
23 
24 
25 
26 
27 

28 
29 
30 

3 1 
32 
33 
34 
35 

36 

37 
38 

39 
40 

4 1 
42 
43 
44 



CALL I NG SEQUENCE : 

ADDR = LOC_TO_SYS_ADDR( PTR ); 



1 ! ! ] ) ! 1 ! ! ) I ) ! 1 ! ! 1 ) 



] ! ! 1 ! ) ! I I ! 1 1 ! 1 ) 

CGROUP GROUP CODE 
ASSUME CS : CGROUP 

CODE SEGMENT BYTE PUBLIC 'CODE' 



PUBLIC LOC_TO_SYS_ADDR 
LOC_TO_SYS_ADDR : 

POP DI 

POP SI 

POP AX 



XOR DX , DX 

DWORD 

MOV CX , 4 

LTSA_1 : 
CLC 

RCL AX , 1 
RCL DX , 1 
LOOP LTSA_1 

ADD AX , SI 
OFFSET 

ADC DX , 1 OH 



MOV BX , AX 
WELL 

MOV ES , DX 

JMP DI 

CODE ENDS 
END 



THE RETURN ADDRESS 
THE OFFSET 
THE BASE 



CONVERT BASE TO 



AND ADD IT TO THE 
SETTI NG BIT 25 TO 1 

RETURN AS PO I NTER AS 
RETURN 



ASSEMBLY COMPLETE, NO ERRORS FOUND 



SERIES-III 8086/8087/8088 MACRO ASSEMBLER VI. 1 ASSEMBLY OF MODULE COPY 

NO OBJECT MODULE REQUESTED 

ASSEMBLER INVOKED BY: ASM86.86 : F 1 : C P Y . A 8 6 P A G E W I D T H ( 7 8 ) NOOJ 



LOC OBJ 



L I NE 



SOURCE 



400 
2 102 



1 
2 
3 
4 
5 
6 
7 
8 
9 
1 
1 1 



NAME 



COPY 



! ) I > ! I ) 1 ! 1 ) ! I I ! 1 1 ! ) ) 



! ! ! 1 ) 1 ! ! 1 1 1 1 ) 1 ] 



THIS MODULE CONTAINS THE ROUTINES 
1 . S YS_TO_L OC_ADDR 

2. SAVE_ADDRESS_SPACE 

3. RESTORE_ADDRESS_SPACE 



! 1 ! ! ) ) 



1 ! ) ) 1 ! ! ) I ) ) 1 ! ! ! ) ! ) ! 1 ) 1 I ) 1 1 J ! 



BASE_552 EQU 

MB_WINDOW EQU 

CGROUP GROUP CODE 



4000H 
2 1 02H 
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0000 ?? 



0000 

0000 5E 

000 1 58 

0002 5A 

0003 A F 6 
0005 75 11 

0007 BF0040 

A 8EC7 

000C BF022 1 

OOOF 2688 1 5 

00 12 88 160000 

00 16 B208 

00 18 

00 18 B90C0 

00 1B 50 



00 1 C 

1 C F8 

00 1D D1 DO 

00 1 F D 1 D2 

002 1 E2F9 



023 58 
0024 250F0 



1 2 
1 3 
1 4 
1 5 
16 

1 7 
18 
19 
20 

2 1 
22 
23 
24 
25 
26 
27 
28 
29 
30 

3 1 
32 
33 
34 
35 
36 
37 
38 
39 
40 

4 1 
42 
43 
44 
45 

46 
47 
48 
49 

50 

5 1 
52 
53 

54 
55 
56 

57 
58 
59 
60 

6 1 
62 
63 
64 
65 
66 



DGROUP GROUP DATA 

ASSUME CS : CGROUP , DS : DGROUP 

DATA SEGMENT PUBL I C 'DATA ' 
C U R_W I N D W DB ? 

; TO SAVE THE VALUE OF THE CURRENT 
; MBUS UI NDOW 
DATA ENDS 



CODE SEGMENT BYTE PUBLIC 'CODE' 



117 11 



FUNCTION: 
I F ADDRESS > 1 6 MBYTES 

CONVERTS 24 BIT ADDRESS TO PLM86 

PO I NTER 
ELSE SETS MULTIBUS WINDOW TO ACCESS 

24 BIT ADDRESS AND RETURNS POINTER 

TO ACCESS THE ADDRESS 

CALLING SEQUENCE : 
PTR = SYS_TO_LOC_ADDR( ADDRESS ); 



) ) ! ! ) ) ! 1 ! 1 ! ! 1 I 1 ] ! 1 ! I ] I ) ! ! ) 1 ) I 1 1 1 1 

PUBLIC SYS_TO_LOC_ADDR 

SYS_TO_LOC_ADDR : 

POP SI ; THE RETURN ADDRESS 

POP AX ; THE LSW OF THE ADDRESS 

POP DX ; THE MSW OF THE ADDRESS 

OR DH, DH ; GREATER THAN 16 MBYTES 
JNZ STLA_1 ; IT NOT THEN GOTO STL A_ 1 

MOV DI, BASE_552 ; SET THE MBUS 
WI NDOW 

MOV ES , DI 

MOV DI , MB_WI NDOW 

MOV BYTE PTR ES:[DI], DL 

MOV CUR_WINDOW, DL ; NOTE THE ADDRESS 
OF CURRENT WIDOW 

MOV DL, 8 ; MBUS MAPPING AT 8000:? 



STLA_1 : 

MOV CX , 12 
TO PO I NTER 

PUSH AX 



CONVERT LOW(DL) : BX 
SAVE LSW 



; GET BASE OF THE POINTER IN THE DX 
REGI STER 
STLA 2 : 

CLC 

RCL AX , 1 

RCL DX , 1 

LOOP STL A_2 

; GET THE OFFSET OF THE POINTER IN AX 
POP AX 
AND AX , OFH 



C-9 



0027 8BD8 67 MOV BX, AX ; RETURN AS POINTER 

0029 8EC2 68 MOV ES , DX 

69 

2 B FFE6 70 JMP SI ; RETURN 

7 1 

' c 1 ! ! ! ! ! ) ) ) 1 ! 1 ! ! 1 I ! ) 1 ! ! 1 1 ! I 1 1 ) ) ) ) 1 ! ) I ) 1 1 

73 ;; SAVES THE PARM PERTAINING TO THE 

74 ;; CURRENT ADDRESS SPACE ON THE STACK 
' « ! i i ! i ! i ! ! ! ! ! J i ! ! ! i ! ! ! ! i ! ! ! 5 ! ! ! i i ! 5 ! ! i ! 
76 PUBLIC SAVE_ADDRESS_SPACE 

002D 77 SAVE_ADDRESS_SPACE : 

002D 5F 78 POP DI ; THE RETURN ADDRESS 

002EFF360000 R 79 PUSH WORD PTR C U R_W I N DO W ; THE CURRENT 

ADDR SPACE 

032 FFE7 80 JMP D I ; RETURN 

8 1 

"^ i!i>iiiiiiiiiSiSii)iii)iii))Sii!iit>ii 

83 ;; RESTORES THE ADDR SPACE SAVED BY 

84 ; ; THE PRECEEDI NG CALL 

"3 ! 1 1 1 1 i 1 1 ! 1 ) ) ) ) 1 1 1 1 1 1 ) 1 ! 1 ) 1 ) 1 ! 1 1 1 1 1 1 1 1 ) 

86 PUBLIC RES-TOR E_A D D R E S S_S PACE 

0034 87 RESTORE_ADDRESS_SPACE : 

0034 5F 88 POP DI ; THE RETURN ADDRESS 

0035 58 89 POP AX ; THE OLD ADDR SPACE 

90 

0036 BB0040 91 MOV BX, B A S E_5 5 2 ; NOW SET THE 

ADDRESS SPACE OF 

00398EC3 92 MOV ES,BX ; THE 552 TO THAT 

STORED IN AX 

003B BB0221 93 MOV BX, MB_WINDOW 

003E 268807 94 MOV BYTE PTR E S : [B X] , AL 

95 

004 1 FFE7 96 JMP DI ; RETURN 

97 
98 CODE ENDS 

99 END 

ASSEMBLY COMPLETE, NO ERRORS FOUND 
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APPENDIX D 
CONFIGURE COMMAND PARAMETERS 



The data link CONFIGURE command is used to load the 82568 (or the iSBC 550 
FW) with its operating parameters. In addition, the DL_CONF configuration macro 
is used to load the operating parameters in a similar manner during initialization. 
This appendix gives the format for the CONFIGURE command argument field and 
describes the command parameters. For more information on the particular param- 
eters, see the 82586 Reference Manual or the iSBC 550 Ethernet Controller Kit 
Programmer' s Manual. 

Figure D-l shows the format of the CONFIGURE command argument field. This 
field has the same format for both the 82586 and iSBC 550FW controllers. 

Table D-l lists the CONFIGURE command parameters. The iSBC 550FW control- 
ler only recognizes a subset of the 82586 configuration parameters. Those relevant to 
the iSBC 550FW controller are identified by an asterisk beside the parameter 
mnemonic. 




Figure D-l . CONFIGURE Command Argument Field 
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Table D-l . Communications Controller Configuration Parameters 



Byte 


Bit(s) 


Mnemonic 


Default 


Description 


1 


0-3 


BYTE-CNT* 




Byte count. Number of bytes, including this one, 
that hold parameters to be configured. A value 
greater than 12 is truncated to 12. A value less 
than 4 is interpreted as 4. In word mode, if the 
value is an odd number, the last byte is truncated. 


2 
3 


0-3 
6 


FIFO-LIM 


8 



FIFO limit value. 


SRDY/ARDY 


— SRDY/ARDY pin operates as ARDY 
(internal synchronization). 


1 — SRDY/ARDY pin operates as SRDY 
(external synchronization). 




7 


SAV-BF* 





— Received bad frames are not saved in 

memory. 

1 — Received bad frames are saved in memory. 


4 


0-2 


ADDR-LEN 


6 


Number of address bytes. Note: 7 is interpreted 
asO. 




3 


AC-LOC* 





— Address and Type fields are separated from 

data and associated with Transmit 
Command Block or Receive Frame 
Descriptor. For transmitted frame, the 
Source Address is generated by the 82586. 

1 — Address and Type fields are part of the 

transmit/receive data buffers, including the 
Source Address. 




4-5 


PREAM-LEN 


2 


Preamble Length, including the Beginning of 
Frame indicator. Values are as follows: 

00 — 2 bytes 

01—4 bytes 

10 — 8 bytes 

11—16 bytes 




6 


INT-LPBK* 





— No internal loopback. 

1 — Internal loopback (if bit 7 = 1). 




7 


EXT-LPBK 





— No external loopback. 

1 — External loopback. 


5 


0-2 


LIN-PRIO 





Linear Priority. 




4-6 


EXP-PRIO 





Exponential Priority. 




7 


BOF-MET 





Exponential Backoff Method. 

— Ethernet. 

1 — Short Topology and/or Low Bit Rate 

(Interframe Spacing shorter than the Slot 
Time). 


6 


0-7 


IF-SPACING 


96 


Interframe Spacing in TXC period units. A value 
less than 32 is interpreted as 32. 


7 


0-7 


SLT-TM(L) 





Slot Time number, low byte. 


8 


0-2 


SLT-TM(H) 


1 
(512) 


Slot Time number, high byte. Slot Time is the 
number of TXC period units. Slot Time number 
= is interpreted as 2048 (211). 




4-7 


RETRY-NUM* 


15 


Number of transmission retries on collisions. 


9 





PRM* 





Promiscuous Mode. 

— Non-promiscuous address filtering mode. 

1 — Promiscuous mode. 




1 


BC-DIS* 





Broadcast Disable. 

— Broadcasted frames accepted. 

1 — Broadcasted frames rejected. 




2 


MANCH/NRZ 





Manchester or NRZ encoding/decoding. 

— NRZ. 

1 — Manchester. 
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CONFIGURE Command Parameters 



Table D-l . 


Communications Controller Configuration Parameters (Cont'd . ) 


Byte 


Bit(s) 


Mnemonic 


Default 


Description 




3 


TONO-CRS 





Transmit on No Carrier Sense. 

— Cease transmission if CRS goes inactive 

during frame transmission (after pream- 
ble is sent). 

1 — Continue transmission even if there is No 

Carrier Sense. 




4 


NCRC-INS 





No CRC Insertion. 

— 82586 generates and appends CRC to 

transmitted frames. 

1 — Disables the internal logic that generates 

CRC. 




5 


CRC-16 





CRC Type. 

— 32-bit Autodin II CRC polynomial. 

1 — 16-bit CCITT CRC polynomial. 




6 


BT-STF 





Bitstuffing. 

— End of Carrier mode (Ethernet). 

1 — HDLC-like Bitstuffing mode. 




7 


PAD 





Padding. Note: PAD has meaning only for 
Bitstuffing. In the End of Carrier mode, PAD is 
internally forced to 0. 

— No Padding. 

1 — Perform padding by transmitting flags for 

the rest of the Slot Time. 


10 


0-2 


CRSF 





Carrier Sense Filter bits. 




3 


CRS-SRC 





Carrier Sense Source. 

— Carrier Sense signal externally 

generated. 

1 — Carrier Sense signal internally generated. 




4-6 


CDTF 





Collision Detect Filter bits. 




7 


CDT-SRC 





Collision Detect Source. 

— Collision Detect signal externally 

generated. 

1 — Collision Detect signal internally 

generated. (Works for a transceiver that 
does not feed back the transmitted signal 
on the receive pair). 


11 


0-7 


MIN-FRM-LEN 


64 


Minimum Frame Length in bytes. Frames shorter 
than MIN-FRM-LEN are treated as bad frames. 
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APPENDIX E 
MULTIBUS" INTERPROCESSOR 

PROTOCOL (MIP) 



E.1 What is MIP? 

The MULTIBUS Interprocessor Protocol (MIP) is a specification of a set of mecha- 
nisms and protocols that enable reliable and efficient exchange of data among tasks 
executing on various single-board computers connected to a common MULTIBUS 
system bus. Since MIP is a specification, it becomes useful only when it is imple- 
mented. This implementation is known as a MIP facility. The MIP specification 
ensures compatibility among MIP facilities. For an example of how MIP facilities 
are used in a MULTIBUS configuration of single-board computers, see Figure E-l. 
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Figure E-l . A MIP System 
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MIP facilities isolate user tasks from the complexities of communicating across the 
MULTIBUS system bus. Without MIP facilities tasks trying to communicate across 
the bus would have to solve one or more of the following problems: 

• The tasks may be running on different kinds of processors. 

• The tasks may be running under different kinds of operating systems. 

• Different boards have different MULTIBUS signaling mechanisms. 

• Not all boards share the same memory space. 

• Boards sometimes share memory but reference it by different addresses. 

• Tasks sharing areas of memory may interfere with one another if not correctly 
coordinated. 

MIP facilities hide these details from user tasks, thereby making it easier to develop 
programs for MULTIBUS configurations that include several intelligent boards. 

MIP supports communication among intelligent devices such as single-board 
computers and intelligent device controllers. MIP can be used by any device on which 
a MIP facility can be programmed. The design of MIP does not limit the kinds of 
processors or operating systems that can execute MIP facilities. MIP can be used by 
the MCS-85 or the iAPX-86 families of processors. MIP facilities can run under the 
ISIS-II, iRMX-80, iRMX-86 or iRMX-88 operating systems. In addition, MIP 
facilities can run on other processors and under other operating systems. 



E.2 Implementing MIP 

When using this specification as a guide for implementing MIP, be aware that it 
deals only with global concerns; implementational details (for example, initialization 
or memory management) are not addressed. You may add features that enable your 
implementation to better interface with its local environment (e.g., the processor, the 
operating system, or application tasks). Be aware also that the specification assumes 
a general processing environment. For example, the algorithms in the specification 
are designed to work in a multitasking environment. If your environment is simpler, 
you may streamline your implementation as long as you retain the basic protocol 
needed to communicate with other versions of MIP. 

When implementing MIP using the MIP model, follow these guidelines: 

• If an element or structure is never shared with another MIP facility, then its 
function in the model is merely descriptive. 

• If an algorithm requires the cooperation of another communicating MIP facility, 
then the algorithm is required. 



E.3 The MIP Model 
E.3.1 Basic Components 

A software application consists of several functional units called tasks. A task may 
be a program, a part of a program or a system of related programs. 

MIP facilities support communication among tasks that are executing on different 
processor boards attached to a common MULTIBUS system bus. A MIP facility is 
a functioning implementation of MIP. The set of intercommunicating tasks, along 
with associated processor boards, operating systems and MIP facilities, is called a 
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MIP system. Each processor board in a MIP system runs a MIP facility. Each MIP 
facility may be a different implementation of MIP, but adherence to this specifica- 
tion ensures compatibility among them. 

The term device is used for each processor board in a MIP system. Each device has 
a device-ID, a number ranging from zero to the number of devices communicating in 
one MIP system (less 1). 

Any two tasks can communicate with each other by passing data in an area of memory 
that is accessible by both of the devices on which the tasks execute. A contiguous 
block of memory through which data is passed under control of MIP facilities is 
called a buffer. The content of buffers is not interpreted by MIP facilities. 

Communications are delivered at ports. A port is a logical delivery mechanism that 
enables delivery mfirst-in, first out (FIFO) order. In the MIP model, a port is repre- 
sented as a queue. In some operating systems ports are called mailboxes or exchanges. 
The ports at a given device are identified by a port-ID, a number that ranges from 
zero to the number of ports (less 1) at the device. To provide system-wide addressa- 
bility a port is also identified by a socket, a pair of items in the form (d,p ) where d 
is the device-ID and p is the port-ID. 

Refer now to Figure E-2. Task B on device is receiving communications at port 1, 
also known as socket (0,1). Task C is active at socket (1,0). Socket (1,1) is not active 
(no task is receiving messages). Socket (2,1) is not defined. 

Each port is also known by a function-name. Function-names are symbolic means of 
identifying ports, making tasks that identify ports by their function-names independ- 
ent of changes in configuration. 



E.3.2 Three-Level Structure 

The MIP model is composed of three levels of interface: 

1. The virtual level, by which user tasks interact with the MIP facility. 

2. The physical level, by which MIP facilities on different devices interact with 
each other. 

3. The logical level, which translates between the virtual level and the physical level. 

An implementation of MIP must rigidly adhere to the functions, structures, and 
constants specified here for the physical level. Any implementation that deviates from 
this requirement is not compatible with the MIP architecture and may not be able to 
communicate with other MIP facilities. 

At the logical level, however, the algorithms and data structures specified here merely 
impose a logical framework. Implementations need only satisfy the relationships 
between events and actions, but do not need to duplicate either the algorithms or data 
structures as defined. 

The virtual level of the model simply suggests one way for tasks to view the MIP 
system. Any other viewpoint will work as well as long as the information passed 
through the virtual level interface is sufficient to accomplish the desired results. You 
may wish to create an interface that is more consistent with the interfaces to the 
operating system you are using. 

Figure E-3 illustrates the three-level structure. Refer to this figure during the follow- 
ing discussion. 
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Figure E-2 . A Configuration of Ports 
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Figure E-3 . Data-Flow Structure of the MIP Model 
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E.3.3 Physical Level 



The physical communication mechanism between devices is a fixed size, undirec- 
tional, FIFO queue called a request queue. An element in a request queue is known 
as a request queue entry (RQE). An RQE is added to a request queue at the give 
end of the queue and removed from the take end. Each request queue is managed by 
a request queue descriptor (RQD). An RQD and associated RQE's forming one queue 
occupy a contiguous block of memory as illustrated in Figure E-4. The RQD keeps 
track of the give and take locations, and other information about the queue. 



Each request queue contains at least two RQEs, and each queue is accessed at the 
give end by only one device and at the take end by only one device. This helps to 
avoid memory contention between devices using the same queue. 



Two-way communication between two devices is implemented by a pair of request 
queues, known collectively as a channel. The device that uses the give end of a request 
queue is the owner of the queue. The owner is responsible for initializing the queue. 
See Figure E-5 for a conceptual diagram of a channel. 
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RQE 
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Figure E-4 . Format of a Request Queue 
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Figure E-5 . Conceptual Structure of a Channel 
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E.3.4 Logical Level 

The logical level of the MIP model uses request queues to transfer requests between 
source and destination MIP facilities. A request is either a command or a response. 
A command is an order sent from a source MIP facility to a destination facility. A 
response is returned from the destination facility to the source facility and indicates 
the result of an attempt to deliver a command. The request queues carry these requests 
and their associated parameters between MIP facilities. 

The primary procedures of a logical level are INSTASK and OUTSTASK. In the 
MIP model these are viewed as asynchronous tasks, thereby giving the flexibility 
needed to service several user tasks simultaneously in a multitasking environment. 
Because they are asynchronous, all communication with INSTASK and OUTSTASK 
is through queues. There is one port queue for each destination task and one response 
queue for each source task. For each channel there is one command ready queue, one 
response turnaround queue and one incoming and one outgoing request queue. (See 
Figure E-3.) 

In the MIP model the port queue may contain entire buffers for reasons discussed 
below under "Buffer Movement." The other queues contain only buffer descriptors, 
thereby minimizing movement of data in memory. 

INSTASK is driven by its incoming request queues. Requests in these queues may 
be either commands or responses. Commands are routed to the port queue of the 
destination port; a response is generated and queued in the response turnaround queue 
to be sent back to the source MIP facility by OUTSTASK. Responses from the 
incoming request queues are routed to the response queue of the originating task. 
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OUTSTASK is driven by the command ready queues and response turnaround queues. 
When OUTSTASK finds a command in one of its command ready queues, it routes 
it to the destination device's request queue. (When a destination device is not 
functioning, OUTSTASK sends a response directly back to the sending task's response 
queue.) When OUTSTASK finds a response in one of the response turnaround queues, 
it routes it to the request queue of the source tasks's device. 



E.3.5 Virtual Level 

User tasks interact with the MIP facility via the following five procedures. 

For sending buffers: 

1. FIND locates a port, given its function-name. 

2. TRANSFER initiates transfer of a buffer to a given port by placing a command 
in the destination device's command ready queue. TRANSFER then waits for a 
response before allowing the sending task to continue. 

For receiving buffers: 

3. ACTIVATE attaches a task to a port and enables reception of messages at that 
port. 

4. RECEIVE completes transfer of a buffer by taking a command from the task's 
port queue. 

5. DEACTIVATE disconnects a task from its port and terminates reception of 
commands at that port. 

E.3.6 Memory Management 

Devices in a MIP system communicate via shared memory. The abilities of the devices 
to access the memory available on the MULTIBUS system bus can be used to define 
a partition of that memory. The MIP model partitions all of memory into non- 
overlapping segments so that, for any segment and any device, either the segment is 
continuously addressable within the address space of the device, or the device cannot 
address any of the segment. 

Each segment that can be shared among devices is called an interdevice segment 
(IDS) and is identified by an IDS-ID (a number ranging from zero to the number of 
IDS's (less 1 ) in the MIP system). 

Figure E-6 presents a hypothetical memory configuration and shows how the address 
space is partitioned. Processor A and processor C can communicate through IDS 1. 
Processor B and processor C can communicate through IDS's 0, 1 and 3. IDS 3, 
however, is a segment of dual-ported memory and is accessed by processor B using a 
different range of addresses than processor C uses. Memory segments A, B, and C 
cannot be used for interdevice communication. 

Table E-l summarizes the memory configuration shown in Figure E-6. The table 
shows the lowest address (the base address) by which each device can access each 
IDS. 
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Figure E-6 . Example of Interdevice Memory Segments 
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Table E-l . System Interdevice Segment Table 



IDS 


Length 


Base Addresses 


Device 



Device 
1 


Device 
2 



1 
2 


8000H 
8000H 
8000H 


10000H 


18000H 
10000H 
8000H 


1800.0H 
10000H 
20000H 



The MIP model contains special features for handling the "alias" problem posed by 
dual-port memory. Dual-port memory may be addressed differently from the 
MULTIBUS system bus than from its local processor. The only case of a shared 
memory address in a MIP system is the buffer pointer in the RQED. This pointer is 
stored in a special format, called an IDS pointer, that is independent of the address- 
ing peculiarities of the different devices in a MIP system. The MIP pointer is 32 bits 
wide, permitting an addressing range of 4 gigabytes. The high-order word (16 bits) 
of the pointer stores the low-order word of the address, and the low-order word of the 
pointer stores the high-order word of the address. Within each word the low-order 
byte is stored before the high-order byte. 
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When a buffer is transferred, the sending MIP facility converts the local buffer pointer 
to the MIP pointer format and normalizes it by subtracting the IDS base address of 
the sending device. Upon receiving the RQE, the receiving MIP facility adds the IDS 
base address of the receiving device and converts to the format required by the receiv- 
ing device's processor. In this way user tasks are not concerned with these addressing 
problems. 



E.3.7 Buffer Movement 

Generally, buffers are not physically moved from one memory location to another 
any more often than necessary. Instead, buffers are referenced by descriptors in the 
RQEs. However, the MIP model provides for operating systems whose memory 
management policies forbid introduction of new objects (buffers) into their memory 
spaces. When delivering a buffer, the MIP model copies the buffer from the space 
managed by the sending operating system into the space managed by the receiving 
operating system. In such a case a special status code is returned so that the sender 
can know when the buffer is available for reuse. 



E.3.8 Signaling 

MIP uses a signaling mechanism for efficient utilization of the interdevice request 
queues. The mechanism is a software handshake using flags in the signal bytes of the 
RQDs. This mechanism permits MIP facilities to decrease their activity when queue 
activity decreases. 

INSTASK does not examine incoming request queues that are known to be empty. 
When the OUT$TASK of a sending facility puts a request in an outgoing queue that 
was previously empty, it also sets a flag to signal the INSTASK of the receiving 
facility that the queue is no longer empty. 

Similarly, OUTSTASK does not examine outgoing request queues that are known to 
be full. When the IN$TASK of a receiving facility removes a request from an incom- 
ing queue that was previously full, it also sets a flag to signal the OUTSTASK of the 
sending facility that the queue is no longer full. 

When a MIP facility sets a signal flag it may generate an interrupt for the destina- 
tion processor. A MIP facility designed to respond to interrupts does not need to 
examine its signal flags until it receives an interrupt. Reception of an interrupt signi- 
fies either that a previously empty input queue now has at least one entry or that a 
previously full output queue now has at least one empty space. By scanning the signal 
flags of all devices, the MIP facility can determine which device generated the 
interrupt. 

There are several techniques available for generating interrupts. Which of the follow- 
ing methods you use depends both on the capabilities of the devices involved and on 
the requirements of the processing environment. 

• NO INTERRUPT. The device polls the RQD. This technique is suitable if a 
processor is running only one task or if there is some way of guaranteeing that 
the RQDs are examined regularly. 

• I-O MAPPED. Some devices (such as the iSBC 550 Ethernet Communications 
Board) recognize a write to a specific 1-0 port address as an interrupt. This 
technique is highly reliable; it should be used when available. 

• MEMORY MAPPED. Some devices (such as the iSBC 544 Intelligent Commu- 
nications Controller) recognize a write to a specific memory address as an inter- 
rupt. This technique is also reliable. 
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EDGE LEVEL. The sending device raises one of the MULTIBUS interrupt lines 
after lowering it briefly. The rising edge triggers a processor interrupt. This 
technique is available on most current Intel processor boards, such as the 80/30, 
80/24, and 86/12A. 

PURE LEVEL. The sending device asserts one of the MULTIBUS interrupt 
lines. (If the interrrupt line is shared by several devcies, the sending device must 
drop the line after a limited time to avoid continually reinterrupting all the 
devices.) If the receiving processor has interrupts enabled and is not busy 
processing other interrupts during this time, an interrupt is triggered. You must 
implement some kind of signal (such as another interrupt) that enables the 
receiving device to cause the sending device to drop the interrupt line before the 
receiving device services the interrupt. To guard against missed interrupts the 
receiving MIP facility should periodically poll the signal flags in its incoming 
request queues. 



E.3.9 Error Handling 

The MIP architecture provides for device failure. A device is assumed to have failed 
if it does not return a response to a command within a certain time. The timeout 
period is implementation-dependent. 

When a MIP facility determines that a destination device has failed, it takes three 
actions: 

1. It sets flags to prevent any further activity on the channel. 

2. It discards any responses destined for the dead device. 

3. It returns all commands for the dead device to the tasks that invoked them (along 
with an appropriate error indication). 

Any further recovery actions are application dependent. 



E.4 Procedural Specification 
E.4.1 Data Types 

The following data types are used in the algorithmic specification of MIP. 
BYTE. Standard 8-bit variable. 
WORD. Two-byte variable. 

IDENTIFIER. Byte variable generally used as an index into an array. 
STATE. Byte variable restricted to state constants. 
POINTER. Device-dependent address reference. 
IDSSPTR. Two-word, device-independent address reference. 

E.4. 2 Processor-Dependent Subroutines 

All machine-dependent logic in the algorithmic specification is isolated in the follow- 
ing procedures. In addition to these procedures, the value NULLSPTR is used for 
some unique pointer value that can serve to indicate a null value. For example: 

DECLARE NULL$PTR LITERALLY ' H ' ; 
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PTRSADD 

Any implementation of MIP must handle pointer arithmetic according to the require- 
ments of the processor that executes that implementation. Pointer arithmetic is used 
to calculate the addresses of request queue elements. 

PTR$ADD: PROCEDURE (PTR, SCALAR) POINTER; 

DECLARE PTR POINTER, I* Input. «/ 

SCALAR BYTE; 

DECLARE NEWIPTR POINTER; /» Local. */ 

/ * 

Using knowledge of processor-dependent POINTER 
implementation, add PTR to SCALAR giving NEW$PTR 

♦ / 

RETURN NEW$PTR; 
END PTRIADD ; 



E.4.3 CONVERT$LOCAL$ADR 

This routine converts from an address pointer in the local address space to an IDS- 
relative pointer in the IDSSPTR format. Details of this conversion depend on the 
pointed format dictated by the local processor. 

CONVERTILOCALI ADR : PROCEDURE (IDSIID, BUFFER$PTR, 
M I P$PTR) ; 

DECLARE I D S $ I D IDENTIFIER, I* Input. */ 
BUFFER$PTR POINTER; 

DECLARE MIPIPTR IDS$PTR; /» Output. »/ 

/ * 

Get base address for I D S $ I D from IDST. 

Subtract from BUFFER$PTR. 
* / 

END C0NVERT$L0CAL$ ADR ; 



E.4.4 CONVERT$SYSTEM$ADR 

This routine converts from an IDS-relative pointer in the IDSSPTR format to an 
address pointer in the local address space. Details of this conversion depend on the 
pointer format dictated by the local processor. 

CONVERTIS YSTEMI ADR : PROCEDURE (IDSIID, MIPIPTR, 
BUFFERIPTR); 

DECLARE IDSIID IDENTIFIER, /♦ Input. */ 

MIPIPTR IDSIPTR; 
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DECLARE BUFFER$PTR POINTER; /* Output. */ 

/ t 

Get base address for I D S $ ID from IDST. 

Add to BUFFER$PTR. 
t / 

END C0NVERT!S YSTEM! ADR ; 

E.4.5 TIME$WAIT 

A destination device is assumed to be dead if it does not respond to a command 
within a reasonable period of time. Just how you detect a timeout, however, depends 
on the timing features of the local processor. 

T I M E $ W A I T : PROCEDURE ( T I M E $ U T , RQL$ID); 

DECLARE TIME$0UT WORD, /# Input. */ 

R Q L $ I D IDENTIFIER; 

/ # 

Wait for T I M E ! U T period or until something is 
placed in the response queue identified by R Q L $ I D . 

♦ / 

END TIME$WAIT; 

E.4.6 GENERATE$INTERRUPT 

This routine generates an interrupt to signal another device of a change in queue 
status (from full to not full, or from empty to not empty). 

GENERATES I NTERRUPT : PROCEDURE ( D E V I C E S $ I N D E X ) ; 

DECLARE .DEVICE! I NDEX IDENTIFIER; /* Input #/ 

/ # 

Using interrupt information in the DCM, generate an 
interrupt for the device specified by DEVICE! INDEX . 

# / 

ENDGENERATE!INTERRUPT; 

E.4.7 CLEAR$INTERRUPT 

This routine is used by INSTASK and OUTSTASK to clear the interrupt that invokes 
them. 

CLEAR! I NTERRUPT : PROCEDURE ; 

/* Acknowledge and clear interrupt, if necessary. ♦/ 

END CLEAR!INTERRUPT; 
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E.5 Physical Level 

E.5.1 Request Queue Descriptor 

A request queue descriptor controls a request queue. The request queue descriptor is 
physically located before and adjacent to the associated request queue entries. 

DECLARE RQD$STRUCTURE LITERALLY 'STRUCTURE 

( EMPTY$S I GNAL STATE, 

FULL$SIGNAL STATE, 

RQ$S IZE BYTE , 

RQE $LENGTH BYTE, 

G I VE $ I NDEX BYTE, 

GIVE$STATE STATE, 

TAKE$ INDEX BYTE, 

TAKE $STATE STATE )' ; 

EMPTYSSIGNAL and FULLSSIGNAL are used by the two devices sharing a 
channel to signal each other when there has been some activity on the channel. Signals 
are written in the RQD of the outgoing queue and read from the RQD of the incom- 
ing queue. The signal values are defined below. Unused bits are reserved for future 
expansion. 

DECLARE FULL$N0$L0NGER LITERALLY ' 8 H ' , 
EMPTY$N0$L0NGER LITERALLY ' 1 H ' , 
N0$CHANGE LITERALLY ' H ' ; 

RQSSIZE defines the number of elements in the request queue. RQSSIZE must be 
a power of 2 and must have a value of 2 or greater. 

RQESLENGTH defines the number of bytes in a request queue element (RQE). The 
number of elements is 2 to the power RQESLENGTH. For all queues shared between 
MIP facilities, REQSLENGTH is 4 (i.e., each entry is 16 bytes long). 

GIVESINDEX identifies the request queue element available for enqueuing data. 

TAKESINDEX identifies the request queue element available for dequeuing data. 

DECLARE GIVE$HALT LITERALLY MOH', 
GIVE$FACTOR LITERALLY ' 8 H ' ; 

DECLARE TAKE$HALT LITERALLY MOH', 

TAKE$FACTOR LITERALLY ' 8 H ' : 

GIVESFACTOR and TAKESFACTOR together distinguish between the full state 
and the empty state when GIVESINDEX and TAKESINDEX are equal. 

GIVESHALT and TAKESHALT prevent further activity in the queue when a device 
failure is detected. 
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E.5.2 Request Queue Entry 

A request queue entry is an element of a request queue. 

DECLARE RQE$STRUCTURE LITERALLY 'STRUCTURE 



(REQUEST 
SRC$REQ$ I D 
DEST$DEV$ I D 
DE'ST$PORT$ID 
SRC$DEV$ I D 
DATA $PTR 
DATA $ LENGTH 
I DS$ I D 

0WNER$DE V$ I D 
RSRVD (3) 



STATE , 
I DENT I F 
I DENT I F 
I DENT I F 
I DENT I F 
I DS$PTR 
WORD , 
I DENT I F 
I DENT I F 
BYTE ) ' ; 



I ER 

I ER 

I ER 

I ER 



I ER 
I ER 



REQUEST identifies the RQE as a command or a response using one of the follow- 
ing values: 



DECLARE SEND$COMMAND 

MSG$DEL I VERED$N0$C0PY 
MSG$DELIVERED$COPY 
SYSTEM$MEMORY$NAK 
DE AD$DEV I CE 



LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 



' 7 H ' 

' 80H ' 

' 82H ' 

' 85H ' 

' 89H ' 



SRC$REQ$ID identifies the sending task so that responses can be returned. The 
meaning of the identifier is defined by the local MIP implementation. 

DEST$DEV$ID is the device identifier part of the destination socket. 

DEST$PORT$ID is the port identifier part of the destination socket. 

SRC$DEV$ID identifies the device from which a request is issued. 

DATASPTR contains the IDS-relative address of a buffer to be delivered or returned 
by a MIP facility. 

DATASLENGTH specifies the number of bytes in a buffer. 

IDSSID tells which interdevice segment contains the buffer. 

OWNER$DEVICE$ID identifies the device that manages or "owns" the buffer. 

RSVRD is undefined space reserved for future expansion. 



E.5.3 Queue Procedure Returns 

The following constants are used to return the results of procedures associated with 
the request queues. 



DECLARE READY LITERALLY ' H 

FULL LITERALLY ' F F H 

EMPTY LITERALLY ' OFFH 

FIRST$GIVE LITERALLY ' 2 H 

F I RSTITAKE LITERALLY ' 2 H 

HALTED LITERALLY MOH 

G I VE$D I SABLED LITERALLY ' 1 OH 

TAKE$D I SABLED LITERALLY ' 1 H 

POINTER$MASK LITERALLY ' 7 F H 
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E.5.4 INIT$REQUEST$QUEUE 

This procedure enters a request queue descriptor in memory, thereby initializing a 
request queue. 

I N I T$REQUEST$QUEUE : PROCEDURE (RQD$PTR, RQ$LEN); 



DECLARE RQ$LEN BYTE, 

RQDIPTR PO I NTER , 

RQD BASED RQD$PTR R Q D $ S T R U C T U R E ; 



/* Input. */ 



RQD . EMPTY$S I GNAL 
RQD . FULL$S I GNAL 
RQD . RQ$S I ZE 
RQD . RQE$LENGTH 
RQD . G I VE$ I NDEX 
RQD . TAKE$ I NDEX 
RQD.GIVE$STATE 
RQD . TAKE$STATE 



NOICHANGE ; 

N0$CHANGE ; 

RQ$LEN ; 

4 











END I N I T$REQUEST$QUEUE ; 



E.5.5 TERM$REQUEST$QUEUE 



This procedure sets the request queue flags to prevent subsequent acitivity on a 
channel. 



TERM$REQUEST$QUEUE : PROCEDURE (RQD$IN$PTR, R Q D $ U T $ P T R ) ; 



DECLARE RQD$ I N$PTR POINTER, 

RQD$OUT$PTR POINTER, 

I N $ R Q D BASED RQD$IN$PTR R Q D $ S T R U C T U R E , 

0UT$RQD BASED RQD$OUT$PTR R Q D $ S T R U C T U R E ; 



/» Input */ 



I N$RQD . TAKE$STATE ■ I N $ R Q D . T A K E $ S T A T E OR TAKE$HALT; 
OUTIRQD . G I VE $STATE = U T $ R Q D . G I V E $ S T A T E OR GIVEIHALT; 

END TERM$REQUEST$QUEUE ; 



E.5.6 QUEUE$GIVE$STATUS 



This algorithm returns the status of a request queue without affecting the queue. 



QUEUEIG I VE$STATUS : PROCEDURE (RQD$PTR, STATUS); 



DECLARE RQD$PTR 
STATUS 



PO I NTER , 
BYTE ; 



/* Input */ 
/» Output */ 
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DECLARE RQD BASED RQD$PTR R Q D $ S T R U C T U R E ; 

IF (RQD . TAKE$STATE AND T A K E $ D I S A B L E D ) - T A K E $ D I S A B L E D 
THEN DO ; 

STATUS • HALTED ; 
RETURN ; 
END ; 

IF (RQD . TAKE$STATE AND TAKE$HALT) - TAKE$HALT THEN 
DO ; 

RQD . GI VE $STATE - R Q D . G I V E $ S T A T E OR G I V E $ D I S A B L E D ; 
STATUS = HALTED; 
END ; 
ELSE 

IF ( ( RQD . G I VE $ I NDEX AND P I N T E R $ M A S K ) = 

( RQD . TAKE$ I NDEX AND P I N T E R $ M A S K ) ) AND 
( ( RQD . G I VE$ I NDEX AND GIVE$FACTOR) <> 
( RQD . TAKE$ I NDEX AND T A K E $ F A C T R ) ) THEN 
STATUS » FULL ; 
ELSE 

STATUS - READY; 
RETURN ; 

END QUEUEIGI VE$STATUS ; 



E.5.7 REQUEST$GIVE$POINTER 

This algorithm returns the address of a request queue element from the tail (send 
side) of a request queue, if one is not in use. 

REQUEST$G I VE$PO I NTER : PROCEDURE (RQDIPTR, RQE$PTR, STATUS); 

DECLARE RQD$PTR POINTER, /♦ Input */ 
RQE$PTR POINTER, /♦ Output t / 
STATUS BYTE ; /» Output »/ 

DECLARE RQD BASED RQD$PTR R Q D $ S T R U C T U R E ; 

IF ( RQD . TAKEISTATE AND TAKE$HALT) = TAKE$HALT THEN 
DO ; 

RQD.GIVEISTATE = GIVE$DISABLED; 

STATUS = HALTED; 

RETURN ; 
END ; 
IF ( ( RQD . G I VE$ I NDEX AND P I N T E R $ M A K S ) = 

( RQD . TAKE$ I NDEX AND P I N T E R $ M A S K ) ) AND 

( ( RQD . G I VE$ I NDEX AND GIVE$FACTOR) <> 

(RQD . TAKE$ I NDEX AND T A K E $ F A C T R ) ) THEN 
DO ; 

STATUS = FULL; 

RETURN ; 
END ; 

STATUS = READY ; 
RQE$PTR = SHL( ( RQD . GI VE$ I NDEX AND P I N T E R $ M A S K ) , 

RQD . RQEILENGTH) + 8 + RQD$PTR; 
RETURN ; 

END REQUEST$GIVE$POINTER; 
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E.5.8 RELEASE$GIVE$POINTER 

This algorithm makes a previously give-requested RQE available for take. 

RELEASE$G I VE$P0 I NTER : PROCEDURE (RQD$PTR, STATUS); 

DECLARE RQD$PTR POINTER, /* Input */ 
STATUS BYTE; / * Ou t pu t # / 

DECLARE RQD BASED RQD$PTR R Q D $ S T R U C T U R E , 
TEMP WORD ; 

TEMP = RQD . G I VE $ I NDEX AND GIVE$FACTOR; 

IF ( (RQD . TAKE$ I NDEX AND P I N T E R $ M A K S ) = 

( ( (RQD . G I VE$ I NDEX AND P I N T E R $ M A S K > + 1) AND 
(RQD.RQ$SIZE - 1)) THEN 

TEMP = (NOT ( RQD . TAKE$ I NDEX AND T A K E $ F A C T R ) ) AND 
POINTER$MASK; 
RQD . GI VE$ I NDEX = ( ( ( R Q D . G I V E $ I N D E X AND P I N T E R $ M A S K ) 

+ 1) AND (RQD.RQ$SIZE - 1)) OR TEMP; 
IF ( RQD . G I VE$ I NDEX AND P I N T E R $ M A S K ) = 

( ( ( RQD . TAKE $ I NDEX AND P I N T E R $ M A S K ) + 1) 
AND (RQD.RQ$SIZE - 1)) THEN 
STATUS = FIRST$GIVE; 
ELSE 

STATUS = READY; 
RETURN ; 

END RELEASE $G I VE$PO I NTER ; 

E.5.9 REQUEST$TAKE$POINTER 

This algorithm returns the address of a request queue element from the head (receive 
side) of a request queue. 

REQUEST$TAKE$POINTER: PROCEDURE (RQD$PTR, RQE$PTR, STATUS); 

DECLARE RQD$PTR POINTER, /* Input ♦/ 
RQE$PTR POINTER, /* Output * / 
STATUS BYTE; / * Output*/ 

DECLARE RQD BASED RQD$PTR R Q D $ S T R U C T U R E ; 

IF ( RQD . G I VE$STATE AND GIVE$HALT) ■ GIVE$HALT THEN 
DO ; 

RQD . TAKE$STATE = T A K E $ D I S A B L E D ; 

STATUS = HALTED; 

RETURN ; 
END ; 

IF ( RQD . G I VE$ I NDEX = R Q D . T A K E $ I N D E X ) THEN 
DO j 

STATUS = EMPTY ; 

RETURN ; 
END ; 

STATUS = READY ; 
RQE$PTR = SHL ( ( R Q D . T A K E $ I N D E X AND P I N T E R $ M A S K ) , 

RQD . RQE$LENGTH) + 8 + RQDSPTR; 
RETURN ; 

END REQUEST$TAKE$PO INTER; 
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E.5.10 RELEASE$TAKE$POINTER 

This algorithm makes a previously take-requested RQE available for give. 

PROCEDURE RELE ASE$TAKE$PO I NTER (RQD$PTR, STATUS); 

DECLARE RQD$PTR POINTER, /* Input #/ 
STATUS BYTE; / * Output*/ 

DECLARE RQD BASED RQD$PTR R Q D $ S T R U C T U R E , 
TEMP WORD ; 

TEMP = RQB . TAKE* I NDEX AND TAKE$FACTOR; 
IF ( ( RQD . G I VE$ I NDEX AND P I N T E R $ M A S K ) - 

((( RQD . TAKE! I NDEX AND P I N T E R $ M A S K ) + 1) AND 

( RQD . RQ$S I ZE - 1))) THEN 

TEMP - RQD . G I VE$STATE AND GIVE$FACTOR; 
RQD . TAKE$ I NDEX = ( ( ( R Q D . T A K E $ I N D E X 

AND POINTER$MASK) + 1) 

AND (RQD.RQ$SIZE - 1)) OR TEMP; 
IF ( RQD . TAKE$ I NDEX AND P I N T E R $ M A S K ) - 

( ( ( RQD . GI VE$ I NDEX AND P I N T E R $ M A S K ) + 1) AND 

(RQD . RQ$S IZE - 1 ) ) THEN 

STATUS = F I RST$TAKE ; 
ELSE 

STATUS = READY ; 
RETURN ; 

END RELEASE$TAKE$POINTER; 



E.6 Logical Level Database 
E.6.1 Configuration Constants 

The following constants define the system configuration. In place of the descriptions 
printed in italics, substitute the numbers that apply to your configuration. 

DECLARE DEVICES LITERALLY the number of devices in the MIP system , 

SOCKETS LITERALLY the number of destination ports , 

PORTS LITERALLY the number of local ports , 

H M E $ D E V I C E LITERALLY the identifier of this device , 

TIME$DELAY LITERALLY maximum time to wait for a response before 

a destination device is considered dead , 

I D S $ S LITERALLY the number of entries in the IDS table , 

R Q L $ S LITERALLY the number of local response queues ; 
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E.6.2 Destination Socket Descriptor Table (DSDT) 

The DSDT contains information for locating sockets in a MIP system. Each entry 
associates a socket with a unique funtion-name. The MIP facility on each device has 
a DSDT containing entries for all sockets to which tasks on that device send messages. 

DECLARE DSDT (SOCKETS) STRUCTURE 

( FUNCT I 0N$NAME WORD, 

DEST$DEV$ I D IDENTIFIER, 

DEST$PDRT$ID IDENTIFIER); 

FUNCTIONSNAME is a system-wide name for identifying the socket. 

DEST$DEV$ID is the device identifier of the device on which the socket resides. 

DEST$PORT$ID is the local port identifier for the socket on the destination device. 
For the purposes of the algorithmic specification, DEST$PORT$ID is the index of 
the port in the Local Port Table on the destination device. 



E.6.3 Local Port Table (LPT) 

The Local Port Table is the list of ports and their parameters that are managed by a 
device. For the purpose of this algorithmic specification, the index of a port in the 
LPT is the port's identifier. 

DECLARE LPT (PORTS) STRUCTURE 

( FUNCT I 0N$N AME NORD, 

PORT$QUEUE$PTR POINTER, 

PORTISTATE STATE); 

FUNCTIONSNAME is the system-wide name for identifying the port. 

PORT$QUEUE$PTR is the address of the queue in which messages addressed to 
this port are delivered. 

PORTSSTATE tells whether a task is receiving messages at this port. Messages sent 
to the port are accepted if the port is active, rejected (returned) if the port is inactive. 
Values associated with this item are as follows: 

DECLARE INACTIVE LITERALLY '00H', 
ACTIVE LITERALLY '01H', 



E.6.4 Device to Channel Map (DCM) 

The DCM table is used to route messages among intertask and interdevice request 
queues and to manage the flow of messages into and out of the queues. Each MIP 
facility has one entry in its DCM for every device in the MIP system, including the 
device on which the MIP facility resides. The device identifier of a device is its index 
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into the DCM. Each entry in a DCM represents a possible link between the home 
device and the device associated with that entry. If no such link exists, 
CHANNELSSTATE contains IDLE. 

DECLARE DCM (DEVICES) STRUCTURE 

(CHANNELISTATE STATE, 

RQD$0UT$PTR POINTER, 

RQD$OUT$SIZE BYTE, 

RQD$IN$PTR POINTER, 

RQD$ I N$S I ZE BYTE , 

COM$RDY$QUEUE$PTR POINTER, 
RSP$TRNRND$QUEUE$PTR POINTER, 

INTERRUPT$TYPE BYTE, 

I NTERRUPTS ADDRESS WORD) ; 

CHANNELSSTATE is a local management variable in which the run-time state of 
a channel is maintained. This variable contains the booleans defined below. 

DECLARE SEND$ACTIVE LITERALLY '80H' 

SEND$FULL LITERALLY ' 7FH ' 

RECE I VE$ ACT I VE LITERALLY ' 1 H ' 

RECE I VE $EMPTY LITERALLY ' F E H ' 

DYING LITERALLY ' 4 H ' 

IDLE LITERALLY ' 8 H ' 

RQD$OUT$PTR is the local address of the RQD of the interprocessor queue through 
which commands and responses are sent to the associated device. 

RQD$OUT$SIZE is the number of entries in this queue. 

RQD$IN$PTR is the local address of the RQD of the interprocessor request queue 
through which commands and responses are received from the received device. 

COM$RDY$QUEUE$PTR is the address of the local queue of responses waiting to 
be sent to the associated device. 

RSP$TRNRND$QUEUE$PTR is the address of the local queue of responses waiting 
to be sent to the associated device. 

INTERRUPTSTYPE tells which kind of interrupt the device recognizes as indica- 
tion of a change of queue state. 

INTERRUPTSADDRESS may contain an 1-0 port address, a memory address or 
an interrupt level, depending on INTERRUPTSTYPE. 



E.6.5 Interdevice Segment Table (IDST) 

The IDST defines the attributes of interdevice segments (IDSs). There is one entry 
for each IDC in the MIP system. The entries are indexed by the IDS identifier. 

DECLARE IDST (IDS$S) STRUCTURE 

(L0$PART WORD, 

HI$PART WORD); 

Note that the low-order portion of the IDS base address is stored first, followed by 
the high-order portion. 
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E.6.6 Response Queue List (RQL) 

The RQL is a table of pointers to the request queues used to return the results of a 
buffer delivery attempt. Each entry is assigned to a task for use with the TRANS- 
FER function. The entries are indexed by RQLSID. 

DECLARE RQL (RQL$S) STRUCTURE 

(RSP$QUEUE$PTR POINTER); 



E.7 Local Level Algorithms 

E.7.1 DYING$CHANNEL 

OUTSTASK invokes this subroutine when a device failure is detected. The routine 
disposes of any commands that may be waiting to be sent to the dead device. 

DY I NG$CHANNEL : PROCEDURE ( D E V I C E $ I N D E X ) ; 

DECLARE DEVICE$INDEX BYTE; /* Input. */ 

DECLARE STATUS BYTE, /♦ Local. ♦/ 

RQE$COM$PTR POINTER, 

C0M$RQE BASED RQE$COM$PTR RQE$STRUCTURE, 
RQE$RSP$PTR POI NTER , 

RSP$RQE BASED RQE*RSP$PTR R Q E $ S T R U C T U R E ; 

CALL REQUEST$TAKE$POINTER 

(DCM(DEVICE$INDEX).COM$RDY$QUEUE$PTR, 
RQE $C0M$PTR , STATUS); 
I F STATUS < > EMPTY 
THEN DO; /» Send back D E A D $ D E V I C E response. */ 
CALL REQUEST$GIVE$POINTER 

(RQL(COM$RQE.SRC$REQ$ID).RSP$QUEUE$PTR, 
RQE$RSP$PTR, STATUS); 
CALL MOVE (16, RQE$COM$PTR, RQE$RSP$PTR) ; 
RSPIRQE. REQUEST = DEADIDEVICEj 
CALL RELEASE$GIVE$POINTER 

(RQL(COM$RQE.SRC$REQ$ID).RSP$QUEUE$PTR, 
STATUS ) ; 
CALL RELEASE$TAKE$POINTER 

(DCM(DEVICE$INDEX).COM$RDY$QUEUE$PTR, 
STATUS) ; 
END /» THEN */ ; 

ELSE /♦ Mo more outstanding command. »/ DO; 
DCM(DEVICE$INDEX).CHANNEL$STATE ■ IDLE; 
CALL TERM$REQUEST$QUEUE 

(DCM(DEVICE$INDEX),RQD$IN$PTR, 
DCM(DEVICE$INDEX).RQD$OUT$PTR); 
END /♦ ELSE #/; 
RETURN; 

END DYING$CHANNEL; 
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E.7.2 SERVE$TURNAROUND$QUEUE 

This subroutine of OUTSTASK transfers a response from the response turnaround 
queue to the output queue of the sending device. 

SERVE $TURN AROUND$QUEUE : PROCEDURE ( D E V I C E $ I N D E X , STATUS); 

DECLARE DEVICE$INDEX BYTE; /♦ Input. ♦/ 

DECLARE STATUS BYTE; I* Output. #/ 

DECLARE RQD$PTR POINTER, /♦ Local. ♦/ 

RQD BASED R Q D $ P T R R Q D $ S T R U C T U R E , 
RQE$TRN$PTR POINTER, 

TRN$RQE BASED RQE$TRN$PTR R Q E $ S T R U C T U R E , 
RQE$OUT$PTR POINTER, 

0UT$RQE BASED RQE$QUT$PTR R Q E $ S T R U C T U R E ; 

CALL REQUEST$TAKE$PO INTER 

CDCM(DEVICE$INDEX).RSP$TRNRND$QUEUE$PTR, 
RQE$TRN$PTR, STATUS); 
I F STATUS = READY 
THEN DO ; 
RQD$PTR = DCM(DEV I CE $ I NDEX ) . RQD$OUT$PTR ; 
CALL REQUEST$G I VE$P0 I NTER (RQD$PTR, 

RQE$OUT$PTR, STATUS); 
CALL MOVE (16, RQE$TRN$PTR, RQE$OUT$PTR); 
CALL RELEASE $G I VE$P0 I NTER (RQDIPTR, STATUS); 
I F STATUS = F I RST$G I VE 
THEN DO; /* Gave to an empty queue, so... ♦ / 
RQD.EMPTY$SIGNAL = EMPTY$N0$L0NGER; 
CALL GENERATE $ I NTERRUPT ( D E V I C E $ I N D E X ) ; 
END / ♦ THEN » / ; 
CALL RELEASE $TAKE $P0 I NTER 

(DCM(DEVICE$INDEX).RSP$TRNRND$QUEUE$PTR, 
STATUS); 
END / * THEN * / ; 
RETURN ; 

END SERVE$TURNAROUND$QUEUE ; 

E.7.3 SERVE$COMMAND$QUEUE 

This subroutine of OUTSTASK transfers command from the command wait queue 
to the output queue of the destination device. 

SERVE $COMMAND$QUEUE : PROCEDURE ( D E V I C E $ I N D E X , STATUS); 

DECLARE DEVICE$INDEX BYTE; /* Input. «/ 

DECLARE STATUS BYTE; /* Output. #/ 

DECLARE RQD$PTR POINTER, /» Local. «/ 

RQD BASED RQD$PTR R Q D $ S T R U C T U R E , 
RQE $C0M$PTR POINTER, 

C0M$RQE BASED RQE$COM$PTR RQE$STRUCTURE, 
RQE$OUT$PTR POINTER, 

0UT$RQE BASED RQE$OUT$PTR R Q E $ S T R U C T U R E ; 



E-23 



MULTIBUS® Interprocessor Protocol (MIP) iNA 960 



CALL REQUEST$TAKE$PO INTER 

(DCM(DEVICE$INDEX).COM$RDY$QUEUE$PTR, 
RQE$COM$PTR, STATUS); 

I F STATUS - READY 
THEN DO ; 
RQD$PTR = DCM(DEV I CE $ I NDEX ) . RQD$OUT$PTR ; 
CALL REQUEST$G I VE $P0 I NTER (RQD$PTR, 

RQE$OUT$PTR, STATUS); 
CALL MOVE (1G, RQE$COM$PTR, R Q E $ U T $ P T R ) ; 
CALL RELEASE$G I VE$PO I NTER (RQD$PTR, STATUS); 
IF STATUS = F I RST$G I VE 
THEN DO; /* Gave to an empty queue, so... ♦/ 
RQD . EMPTY$S I GNAL = E M P T Y $ N $ L N G E R ; 
CALL GENERATE$INTERRUPT (DEVICE$INDEX); 
END /* THEN */; 
CALL RELEASE$G I VE$PO I NTER 

(DCM(DEVICE$INDEX).COM$RDY$QUEUE$PTR, 
STATUS) ; 
END / ♦ THEN * / ; 
RETURN ; 

END SERVE$COMMAND$QUEUE ; 



E.7.4 OUT$TASK 

This algorithm manages activity in the output request queues. 

0UT$TASK: PROCEDURE; 

DECLARE DEVICE$INDEX BYTE, /* Local. */ 

STATUS BYTE , 

RQD$PTR POINTER, 

RQD BASED RQD$PTR R Q D $ S T R U C T U R E ; 

/* Initialization. */ 

DO DEVICE$INDEX = TO DEVICES - 1; 
IF DCM(DEV I CE$ I NDEX ). CHANNEL $STATE <= IDLE 
THEN DO ; 
CALL INIT$REQUEST$QUEUE(DCM(DEVICE$INDEX).RQD$OUT$PTR 

DCM(DEVICE$INDEX).RQD$OUT$SIZE); 
DCMCDEV I CE $ I NDEX ) . C H A N N E L $ S T A T E = SENDIACTIVE; 
END /* THEN */; 
END / * DO * / ; 

/♦ Transfer request loop. »/ 

DO FOREVER; 
DO DEVICE$INDEX = TO DEVICES - 1; 
RQD$PTR = DCM(DEV I CE $ I NDEX ) . RQD$ I N$PTR ; 
/* Read signal from in-RQD. */ 
IF RQD.FULLISIGNAL s FULL$NO$LONGER 
THEN DO ; 
DCM(DEVICE$INDEX).CHANNEL$STATE ■ 

DCM(DEV I CE $ I NDEX ) . C H A N N E L $ S T A T E OR R Q D . F U L L $ S I G N A L ; 
CALLCLEAR$INTERRUPT; 
RQD.FULL$SIGNAL = NO$CHANGE; 
END /* THEN */; 
IF (DCM(DEVICE$INDEX).CHANNEL$STATE AND DYING) <> 
THEN CALL D Y I N G $ C H A N N E L ( D E V I C E $ I N D E X ) ; 
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ELSE DO ; 

IF DCM(DEVICE$INDEX).CHANNEL$STATE 
AND SEND$ ACT I VE <> 
THEN DO; /* Look more closely at this channel. * / 
RQD$PTR = DCM(DEV I CE$ I NDEX ) . RQD$OUT$PTR ; 
CALL QUEUE$G I VE$STATUS ( R Q D $ P T R , STATUS); 
IF STATUS = HALTED 

THEN DCM(DEV I CE $ I NDEX ) . C H A N N E L $ S T A T E - DYING; 
IF STATUS = FULL 
THEN DCMCDEV I CE$ I NDEX ) . C H A N N E L $ S T A T E = 

DCMCDEV I CE$ I NDEX ) . CHANNEL! STATE AND SEND$FULL 
/♦ Don't bother with trying to send on this 
channel until it is no longer full. */; 

IF STATUS = READY 
THEN DO ; 

CALL SERVE$TURNAROUND$QUEUE ( D E V I C E $ I N D E X , 
STATUS) ; 
IF STATUS = EMPTY 
THEN CALL S E R V E $ C M M A N D $ Q U E U E 

(DEV I CE$ I NDEX , STATUS); 
END /* THEN */; 
END /♦ THEN */; 
END /* ELSE * / ; 
END / * DO ♦ / ; 
END /♦ FOREVER */; 

END OUT$TASK; 



E.7.5 RECEIVE$COMMAND 

This subroutine of INSTASK transfers a command from an incoming request queue 
to the port queue associated with the socket specified in the command, first checking 
to make sure that the port is active. The routine then generates an appropriate response 
and enters it in the Response Turnaround Queue associated with the sending device. 

RECE I VE $ COMMAND : PROCEDURE ( R Q E $ I N $ P T R ) ; 

DECLARE RQE$IN$PTR POINTER, /♦ Input. */ 

IN$RQE BASED RQE$IN$PTR R Q E $ S T R U C T U R E ; 



DECLARE RQE$MSG$PTR POINTER, /♦ Local 

MSG$RQE BASED RQE$MSG$PTR R Q E $ S T R U C T U R E , 

LOCAL $DATA$PTR POINTER, 

STATUS BYTE; 



IF LPT ( I N$RQE . DEST$P0RT$ I D) . PORT$STATE <> ACTIVE 
THEN INSRQE. REQUEST = SYSTEM$PORT$INACTIVE; 
ELSE DO; /* Deliver command. ♦/ 
CALL REQUEST$GIVE$POINTER 

(LPT(IN$RQE.DEST$PORT$ID).PORT$QUEUE$PTR, 
RQE$MSG$PTR, STATUS); 
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I F STATUS = FULL 
THEN I N $ R Q E . REQUEST = SYSTEM$MEMORY$NAK; 
ELSE DO ; 
CALL C0NVERT$S YSTEM$ ADR ( I N $ R Q E . I D S $ I D , 

IN$RQE.DATA$PTR, LOCAL$DATA$PTR); 
CALL MOVE ( I N$RQE . DATA $LENGTH , /* Copies buffer */ 

RQE$MSG$PTR, L C A L $ D A T A $ P T R ) ; /* to port queue. #/ 
CALL RELEASE$GI VE$P0 INTER 

(LPT(IN$RQE.DEST$PORT$ID).PORT$QUEUE$PTR, 
STATUS) ; 
I N$RQE . REQUEST = M S G $ D E L I V E R E D $ C P Y ; 

/ * NOTE 

Instead of copying the whole buffer, you may copy 
only I N$RQE . DATA$PTR , I N $ R Q E . D A T A $ L E N G T H , 
I N$RQE . IDS$ I D , and I N $ R Q E . W N E R $ D E V $ I D . In this 
case, I N$RQE . REQUEST is set to M S G $ D E L I V E R E D $ N $ C P Y . 
* / 
END /* ELSE */; 
END /* ELSE »/; 

/♦ Create response. ♦/ 
CALL REQUEST$G I VE $P0 I NTER 

(DCM(IN$RQE.SRC$DEV$ID).RSP$TRNRND$QUEUE$PTR, 
RQE$MSG$PTR , STATUS) ; 
CALL MOVE (16, RQE$IN$PTR, R Q E $ M S G $ P T R ) ; 

/ * NOTE 

If I N$RQE . REQUEST is set to M S G $ D E L I V E R E D $ N $ C P Y , 

the only fields that must be returned are 

I N $RQD . REQUEST and I N $ R Q D . S R C $ R E Q $ I D . 
♦ / 

MSG$RQE . DEST$DEV$ I D ■ I N $ R Q E . S R C $ D E V $ I D ; 
MSG$RQE . SRC$DEV$ I D - I N $ R Q E . D E S T $ D E V $ I D ; 
CALL RELEASE $ G I V E $ P I N T E R 

(DCM(IN$RQE.SRC$DEV$ID).RSP$TRNRND$QUEUE$PTR, 
STATUS) ; 
RETURN ; 

END RECEIVE $C0MMAND; 

E.7.6 RECEIVE$RESPONSE 

This subroutine of INSTASK transfers a response from an incoming request queue 
to the response queue of the initiating task. 

RECE I VE $RESP0NSE : PROCEDURE ( R Q E $ I N $ P T R ) ; 

DECLARE RQE$IN$PTR POINTER, /* Input. ♦/ 

INIRQE BASED RQE$IN$PTR R Q E $ S T R U C T U R E ; 

DECLARE RQE$RSP$PTR POINTER, /♦ Local. */ 

STATUS BYTE ; 

CALL REQUESTIGI VE$P0 I NTER 

(RQL(IN$REQ.SRC$REQ$ID).RSP$QUEUE$PTR, 
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RQE$RSP$PTR, STATUS); 
CALL MOVE (16, RQE$IN$PTR, R Q E $ R S P $ P T R ) ; 
CALL RELEASE $G I VE$P0 I NTER 

(RQL(IN$RQE.SRC$REQ$ID).RSP$QUEUE$PTR 
STATUS ) ; 
RETURN ; 

END RECE I VE$ RESPONSE ; 



E.7.7 IN$TASK 

This algorithm manages activity in the incoming request queues. 

IN$TASK: PROCEDURE; 

DECLARE DEVICE$INDEX BYTE, /♦ Local. */ 

RQD$PTR POINTER, 

RQD BASED RQD$PTR R Q D $ S T R U C T U R E , 
RQE$IN$PTR POINTER, 

I N $ R Q E BASED RQE$IN$PTR R Q E $ S T R U C T U R E , 
STATUS BYTE ; 

DO FOREVER ; 
DO DEVICE$INDEX = TO DEVICES - 1; 
RQD$PTR ■ DCM(DEV I CE$ I NDEX ) . RQD$ I N $PTR ; 
IF RQD . EMPTY $S I GN AL = E M P T Y $ N $ L N G E R 
THEN DO ; 
DCM(DEVICE$INDEX).CHANNEL$STATE = 

DCM(DEV I CE $ I NDEX ) . C H A N N E L $ S T A T E OR R Q D . E M P T Y $ S I G N A L ; 
CALL CLEAR$INTERRUPT; 
RQD . EMPTY $S I GNAL = NO$CHANGE; 
END / * THEN »/; 
IF (DCM(DEV I CE$ I NDEX ) . C H A N N E L $ S T A T E AND 

(DYING OR IDLE) = 0) 
AND (DCM(DEV I CE$ I NDEX ) . C H A N N E L $ S T A T E AND 

RECEIVE$ACTIVE <> 0) 
THEN DO; /* serve the input request queue. ♦/ 
CALL REGUEST$TAKE$PO I NTER 

(DCM(DEVICE$INDEX).RQD$IN$PTR, 
RQE$IN$PTR, STATUS); 
I F STATUS = HALTED 

THEN DCM(DEV I CE$ I NDEX ) . C H A N N E L $ S T A T E = DYING; 
I F STATUS = EMPTY 
THEN DCM(DEV I CE$ I NDEX ) . C H A N N E L $ S T A T E = 

DCM(DEV I CE$ I NDEX ) . C H A N N E L $ S T A T E AND R E C E I VE $ E M P T Y 
/♦ Don't bother with looking for input on this 
channel until it becomes active again. */; 

IF STATUS = READY 
THEN DO ; 
IF I N$RQE . REQUEST = SEND$COMMAND 
THEN CALL R E C E I V E $ C M M A N D ( R Q E $ I N $ P T R ) ; 
ELSE CALL R E C E I V E $ R E S P N S E ( R Q E $ I N $ P T R ) ; 
CALL RELEASE$TAKE$POI NTER 

(DCM(DEVICE$INDEX).RQD$IN$PTR, STATUS); 
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IF. STATUS - FIRST$TAKE 
THEN /* Took from a full queue, 50... */ DO; 
RQDIPTR = DCM(DEV I CE$ I NDEX) . RQD$OUT$PTR ; 
/« Post signal in out-RQD. */ 
RQD . FULL $S I GNAL ■ F U L L $ N $ L N G E R ; 
END / ♦ THEN ♦ / ; 
END / * THEN * / ; 
END /♦ THEN * / ; 
END / * DO * / ; 
END / * FOREVER * / ; 

END I N$TASK ; 

E.8 Virtual Level 
E.8.1 Status Constants 

The following values, along with values associated with RQESREQUEST, are 
returned by the virtual level procedures to indicate the results of the procedures. 

DECLARE SYSTEM$PORT$ AVA I L ABLE LITERALLY '84H', 

SYSTEM$PORT$UNKNOWN LITERALLY ' 8 1 H ' , 

SYSTEM$PORT$ ACT I VE LITERALLY '83H', 

SYSTEM$PDRT$ INACTIVE LITERALLY '87H'; 



E.8.2 FIND$SYSTEM$PORT 

This function provides you with the means to locate a socket by its function-name. 

F I ND$S YSTEM$PORT : PROCEDURE ( F U N C T I N $ N A M E , 
SOCKET$DEV I CE , S0CKET$P0RT, STATUS); 



DECLARE FUNCTION$NAME NORD; 

DECLARE SOCKET$DEV I CE IDENTIFIER, 

S0CKET$P0RT IDENTIFIER, 
STATUS 



DECLARE SOCKETS I NDEX 



BYTE ; 
BYTE; 



/♦ Input. »/ 
/ * Output. */ 

/* Local. */ 



DO SOCKET$INDEX = TO SOCKETS - 1; 
IF ( FUNCT I ONINAME = D S D T ( S C K E T $ I N D E X ) . F U N C T I N $ N A M E ) 
THEN DO ; 
STATUS = S YSTEM$PORT$ AV A I LABLE ; 

SOCKET$DEV I CE = D S D T ( S C K E T $ I N D E X ) . D E S T $ D E V $ I D ; 
SOCKETIPORT = DSDT(SOCKET$INDEX).DEST$PORT$ID; 
RETURN ; 
END /♦ THEN ♦/; 
END / # DO * / ; 

STATUS =SYSTEM$PORT$UNKNOWN; 
RETURN ; 

END FIND$SYSTEM$PORT; 
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E.8.3 TRANSFER$BUFFER 

This function generates a command to transfer a buffer to a destination device and 
port. The command is queued in the Command Wait Queue of the destination device. 
The procedure waits for a reply before relinquishing control. 

TRANSFER$BUFFER : PROCEDURE (BUFFER$PTR, B U F F E R $ L E N G T H , 

IDSIID, SOCKET$DEV I CE , S C K E T $ P R T , R Q L $ I D , STATUS) 



DECLARE 



BUFFER$PTR 
BUFFER$LENGTH 
I DS$ I D 

SOCKETIDEV I CE 
S0CKET$P0RT 
R Q L $ I D 



POINTER, 

WORD , 

IDENTIFIER 

IDENTIFIER 

IDENTIFIER 

IDENTIFIER 



/ ♦ Input 



DECLARE STATUS 

DECLARE RQE$PTR 

RQE BASED RQE$PTR 
CALLS STATUS 



BYTE ; 

POINTER, 
RQE$STRUCTURE, 
BYTE ; 



/* Output. »/ 
/♦ Local. ♦/ 



CALL REQUESTIG I VEIPO I NTER 

(DCM(SOCKETIDEVICE).COMIRDYIQUEUEIPTR 
RQE$PTR, CALL$STATUS); 



RQE. REQUEST 
RQE.SRC$REQ$ID 
RQE . DESTIDEVI I D 
RQE.DEST$PORT$ID 
RQE . SRCIDEVI I D 
RQE . I DS $ I D 
RQE . OWNERIDEVI I D 
CALL CONVERT$LOCAL$ADR 
BUFFER $PTR, RQE 
RQE.DATA$LENGTH 



SENDICOMMAND ; 
RQL $ I D ; 
SOCKETIDEV I CE 
S0CEKT$P0RT; 
HOME IDEV I CE ; 
I DS $ I D ; 
HOMEIDEV I CE ; 

(IDSIID, 
. DATA I PTR ) ; 
BUFFERILENGTH 



CALL RELEASEIGIVEIPOINTER 
( DCM( SOCKETIDEV I CE ) 
CALLISTATUS) ; 



COMIRDYIQUEUEIPTR 



CALL TIMEIWAIT (TIMEIDELAY, RQLIID); 

CALL REQUESTITAKE IPO I NTER ( R Q L ( R Q L I I D ) . R S P I Q U E U E I P T R , 

RQEIPTR, CALLISTATUS); 
IF CALLISTATUS = EMPTY 

/* No response came back within TIMEIDELAY period. */ 
THEN DO ; 

DCM( SOCKETIDEV I CE ). CHANNELISTATE = DYING; 
STATUS = DE ADIDEV I CE ; 
END /♦ THEN •/; 
ELSE DO ; 
STATUS = RQE. REQUEST; 

CALL RELEASE ITAKEIPO I NTER ( R Q L ( R Q L I I D ) . R S P I Q U E U E I P T R , 

CALLISTATUS) ; 
END /* ELSE ♦/; 
RETURN ; 

END TRANSFERIBUFFER; 
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E.8.4 ACTIVATE$SYSTEM$PORT 

This funciton enables receipt of messages at a local port. If the port is not currently 
active, the address of the port queue is returned. 

ACT I VATE $SYSTEM$PORT : PROCEDURE ( F U N C T I N $ N A M E , 
PORT$QUEUE$PTR, STATUS); 



DECLARE FUNCT I 0N$NAME WORD, 

PORT$QUEUE$PTR POINTER 



/* Input. */ 



DECLARE STATUS 
DECLARE P0RT$ INDEX 



BYTE ; 
BYTE ; 



/* Output. */ 
/♦ Local. »/ 



DO P0RT$ I NDEX = to PORTS - 1; 
IF FUNCT I 0N$NAME = L P T ( P R T $ I N D E X ) . F U N C T I N $ N A M E 
THEN IF LPT(P0RT$ I NDEX ) . PORTISTATE = ACTIVE 
THEN DO ; 
STATUS = S YSTEM$PORT$ ACT I VE ; 
RETURN ; 
END /♦ THEN » / ; 
ELSE DO ; 
STATUS = S YSTEM$PDRT$ AVA I L ABLE ; 

PORT$QUEUE$PTR = L P T ( P R T $ I N D E X ) . P R T $ Q U E U E $ P T R 
LPT( P0RT$ I NDEX ) . P0RT$STATE = ACTIVE; 
RETURN ; 
END /» ELSE */; 
END /♦ DO ♦/ ; 

STATUS = S YSTEM$PORT$UNKNOWN ; 
RETURN ; 



END ACTIVATE$SYSTEM$PORT; 



E.8.5 DEACTIVATE$SYSTEM$PORT 

This function terminates reception of messages at a port. 

DEACTIVATE$SYSTEM$PORT: PROCEDURE 
(FUNCTION$NAME, STATUS); 



DECLARE FUNCT I 0N$NAME WORD; 
DECLARE STATUS BYTE ; 

DECLARE PORT$INDEX BYTE; 



/t Input. */ 
/* Output. */ 



DO PORT$INDEX = TO PORTS - 1 ; 
IF FUNCTI 0N$NAME = L P T ( P R T $ I N D E X ) . F U N C T I N $ N A M E 
THEN IF LPT(P0RT$ I NDEX) . PORT$STATE = INACTIVE 
THEN DO ; 
STATUS = SYSTEM$PORT$INACTIVE; 
RETURN ; 
END /* THEN ♦/ ; 
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ELSE DO ; 
STATUS = SYSTEM$PORT$ AVA I LABLE ; 
LPT(P0RT$ I NDEX ) . PORTISTATE - INACTIVE; 
RETURN ; 
END / t ELSE ♦/; 
END / t DO * / ; 

STATUS = S YSTEM$PORT$UNKNOWN ; 
RETURN ; 

END DEACTIVATE$SYSTEM$PORT; 



E.8.6 RECEIVE$BUFFER 

This function retrieves a buffer from a port queue if there is a buffer in the queue. 

RECE I VEIBUFFER : PROCEDURE ( P R T $ Q U E U E $ P T R , 
USER$BUFFER$PTR, STATUS); 

DECLARE PORT$QUEUE $PTR POINTER, /* Input. ♦/ 

RQD BASED PORT$QUEUE$PTR RQD$STRUCTURE; 

DECLARE USER$BUFFER$PTR POINTER, I* Output. */ 

STATUS BYTE ; 

DECLARE RQE$PTR POINTER; /♦ Local. »/ 

CALL REQUEST$TAKE $P0 I NTER ( P R T $ Q U E U E $ P T R , 

RQE $PTR , STATUS) ; 
IF STATUS = READY 
THEN DO ; 
CALL MOVE ( RQD . RQE$LENGTH , RQE$PTR, U S E R $ B U F F E R $ P T R ) ; 
CALL RELE ASE$TAKE$PO I NTER ( P R T $ Q U E U E $ P T R , STATUS); 
END / * THEN ♦/; 

RETURN ; 

END RECEIVEIBUFFER; 
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